Então eu gostaria de discutir CASE para integração AOP+OOP+EJB

Olá pessoal,

Estou com a oportunidade de começar um novo projeto e gostaria de usar as melhores práticas possíveis em termos de desenvolvimento orientado a objetos. Isso durante todo o ciclo de vida, não apenas do ponto de vista de programação. Já uso de forma desconectada ferramentas como:
1) ArgoUML ou Jude (documentação UML - principalmente diagrama de classes)
2) Hibernate ou JDO ou EJB Entity Beans para mapeamento objeto-relacional, pois todos os bancos que uso são relacionais.
3) Java para programação Swing/Web/Celular/etc.

Agora, a minha idéia no novo projeto seria (se possível apenas com ferramentas freeware e/ou opensource):
1) Usar uma ferramenta CASE que pudesse documentar o Diagrama de Classes, marcar as classes persistentes, gerar automaticamente o script SQL do BD relacional destas classes e também gerar os arquivos de mapeamento objeto-relacional (por ex., para o Hibernate ou EJB).
Se pudesse fazer engenharia reversa de um BD relacional já existente para classes persistentes no diagrama também seria legal, devido a poder existir alguns BDs legados.
2) Nesta mesma CASE, gerar os esqueletos das classes Java transientes.
3) Pudesse criar estereótipos para as classes transientes que ficarão, por exemplo, na Web, as que ficarão no celular e as que serão EJBs Session ou Message-Driven.

Eu não achei nas ferramentas existentes, nem no pago Rational, algo abrangente assim. Será que realmente não existe? Neste caso, muitas das coisas que eu citei acima nós temos que fazer "na unha" mesmo???

Se eu achasse pelo menos um CASE que modelasse o Diagrama de Classe mas ficasse bem integrado com BDs relacionais (tanto geração de SQL quanto engenharia reversa), já seria bem útil.

Agradeço desde já a atenção,

1) Estude sobre metodologias ágeis, você pdoe até não adotar nenhum, ams preste atenção nos princípios de deisgn
2) Não use Entity Beans, use Hibernate, iBatis, JDO, qualquer coisa

O Jude geraria as classes para você, com xdoclet (ou se você usar Hibernate 3, annotations) você cria o mapeamento automatico, o Hibernate tem uma ferramenta que cria um schema baseado no mapeamento (nem um pouco otimizado, diga-se de passagem).

Qualquer ferramenta UML decente e cara (esqueça Jude) vai te deixar fazer estereótipo para isso, livre eu não conheço.

Integrar modelo relacional e OO de maneira eficiente não é cosia para ferramenta CASE (ainda?). E antes de tudo, lembre-se que quem faz a produtividade não é a ferramenta, é o programador (se não, EJB seriafenomenal

)

Eu conheco Design Patterns e o conceito de desenvolvimento rapido/prototipacao/etc. Contudo, nao é este o foco principal na minha pergunta.

Eu fico imaginando como empresas com grandes equipes de desenvolvimento, onde manter a documentacao de analise integrada com o desenvolvimento é VITAL, conseguem fazer isso.

Pois supondo que hoje temos que "engolir" que o melhor ainda é usar um BD Relacional, e temos que fazer "gambiarras" com ferramentas tipo Hibernate/JDO/Entity Beans para o mapeamento das classes persistentes para tabelas, entao deve (ou deveria) haver alguma ferramenta CASE (mesmo que paga) que eu desenhasse um Diagrama de Classes e ele se integrasse nao apenas a linguagem de programacao (para as classes transientes) mas tambem ao BDR (para as classes persistentes), e conseguisse a qualquer momento tambem recuperar informacoes via engenharia reversa.

Quando se trabalha no esquema "mixto" de documentar um DER em uma ferramenta CASE Relacional, a parte do BDR fica legal, pois a geracao de SQLs fica facil. Neste caso, ainda é necessario usar outra ferramenta CASE OO para documentar/gerar as classes Java transientes. Com isso, temos uma falha ("gap") de documentacao, pois temos que trabalhar no minimo com 2 diagramas (DER e DC) sendo que somente o DC "deveria" ser suficiente.

E ainda, se usamos Hibernate/JDO/etc, o "rolo" de documentacao é pior ainda, pois é necessario colocar a Classe no DB e a Tabela no DER, fora aquele monte de arquivos de mapeamento XML + classes Java persistentes, etc, etc, etc. Manter tudo isso sincronizado e documentado acaba dando mais trabalho do que simplesmente fazer um DERzinho + JDBC/SQLs diretos. Mas nao queremos usar SQL, queremos "fazer de conta" que estamos produzindo softwares de forma "pura" OO.

OBS: A critica acima refere-se inclusive a mim, que uso as ferramentas de persistencia.

OBS: Usei as siglas erradas.
Onde disse AOP (que seria Aspect Oriented Programming) quiz dizer Analise Orientada a Objetos (AOO).
E arrumei OOP para POO (Programacao Orientada a Objetos).

edilmar wrote:Eu fico imaginando como empresas com grandes equipes de desenvolvimento, onde manter a documentacao de analise integrada com o desenvolvimento é VITAL, conseguem fazer isso.

Ate hoje, o melhor jeito de fazer isso que eu ja encontrei eh fazer com que o codigo seja a documentacao. Nao estou falando so de comentarios ou javadoc, mas de tornar o codigo o mais legivel possivel, e fazer com que os testes que provam que a funcionalidade esta la e o codigo esta certo sejam o mais intuitivos quanto possivel. Resumindo, documentacao que nao pode ser executada, refatorada, e provada correta ou consertada junto com o codigo nao serve pra nada, e as vezes mais atrapalha do que ajuda

Entendo que suas observacoes fazem sentido e devem ser consideradas tambem. Contudo, quanto mais complexos sao os sistemas, mas dificil fica de entender toda a logica envolvida dentro das milhares de linhas de codigo.

E quando digo isso, refiro-me nao apenas ao proprio desenvolvedor, que as vezes escreve logicas que so ele entende. O principal objetivo da documentacao é facilitar a vida do grupo de trabalho como um todo, onde a entrada/saida de desenvolvedores ocorre continuamente, e falar para um "novato" no projeto que ele vai ter que olhar milhares de linhas de codigo que estao maravilhosamente documentadas/organizadas/testadas/refatoradas é loucura.

Para qualquer novato, aquele ditado que diz que "uma imagem vale mais que mil palavras" é 100% valido.

E mesmo pensando em um grupo de desenvolvedores que ja tem experiencia em um projeto, mas que trabalham em modulos distintos, os diagramas sao muito importantes para mante-los atentos ao processo global de desenvolvimento.

Portanto, codigo bem feito é importante, mas nao é um balizador de documentacao.

Olá,

Bom, eu tenho experiência numa emrpesa grande (300 desenvolvedores worldwide + terceirizados trabalhando nos mesmos projetos), com um puta sistema de documentação integrado á metodologia e te digo: não funciona.

Recomendo que você leia um pouco sobre Agile Modeling.

Tudo bem... entao digamos que nao funciona 100%, entao vou ser menos exigente: nao tem alguma ferramenta CASE light que eu desenhe um Diagrama de Classes, marque as transientes e as persistentes, e ele gere esqueleto Java para as transientes e script SQL para as persistentes (nem estou exigindo que gere as configs. para o Hibernate, vamos supor que isso eu faco "por fora" com Xdoclet)? Com isso, teria um unico diagrama com, digamos, toda a documentacao "basica" do projeto.

Seria como no desenvolvimento "mixto" ter um DER+BDR e um monte de classes Java via JDBC. Ou seja, manter o tal DER atualizado é facil, e manter o Diagrama de Classes tambem seria.

edilmar wrote:Entendo que suas observacoes fazem sentido e devem ser consideradas tambem. Contudo, quanto mais complexos sao os sistemas, mas dificil fica de entender toda a logica envolvida dentro das milhares de linhas de codigo.

Milhares? Eu estou trabalhando atualmente num sistema onde isso funciona e o codigo esta na casa das milhoes de linhas. O que vc estava dizendo sobre o tamanho do projeto inviabilizar esse tipo de solucao, mesmo?

Pra dar uma ideia melhor, a gente usa um unico tipo de documentacao por aqui, a GML. GML eh um subset da UML especificamente desenvolvido para tornar a comunicacao mais acessivel, rapida e intuitiva, e tem usos praticamente ilimitados. Eis o manual completo:

edilmar wrote:O principal objetivo da documentacao é facilitar a vida do grupo de trabalho como um todo, onde a entrada/saida de desenvolvedores ocorre continuamente, e falar para um "novato" no projeto que ele vai ter que olhar milhares de linhas de codigo que estao maravilhosamente documentadas/organizadas/testadas/refatoradas é loucura.

Para qualquer novato, aquele ditado que diz que "uma imagem vale mais que mil palavras" é 100% valido.

Concodo com o ditado, e eh pra isso que existem lousas, cadernos de rabisco e pessoas mais experientes no sistema que podem explicar conforme o necessario. Isso quer dizer que elas nao precisam perder tempo fazendo diagramas e documentacao sem saber quais serao as perguntas que esses diagramas e documentacao terao que responder.

edilmar wrote:E mesmo pensando em um grupo de desenvolvedores que ja tem experiencia em um projeto, mas que trabalham em modulos distintos, os diagramas sao muito importantes para mante-los atentos ao processo global de desenvolvimento.

Diagramas nao sao importantes, mas se vc trocar "diagramas" por "comunicacao" nesse quote, a coisa melhora bastante:

edilmar remix wrote:E mesmo pensando em um grupo de desenvolvedores que ja tem experiencia em um projeto, mas que trabalham em modulos distintos, a comunicacao eh muito importante para mante-los atentos ao processo global de desenvolvimento.

Qualquer tipo de comunicacao que servir para explicar pras equipes o que cada modulo tem, e como o projeto esta andando, eh valido. Pra que se limitar a diagramas, quando temos e-mail, IM, skype, telefones e possivelmente reunioes face-a-face?

Ou seja, na sua opiniao, diagramas de analise (seja estruturada como DFD, DER, etc, ou orientada a objetos como Diagrama de Classes, Caso de Uso e Sequencia, etc) e a propria UML nao sao "tao uteis" assim? Tanto projetos pequenos como projetos com "milhoes" de linhas de codigo dispensam o uso dos tais diagramas, havendo melhores formas de "comunicacao"?

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Para que serve diagrama de classe, DER e essas coisas todas?

Não é para comunicar alguma coisa referente ao sistema? Eles não são nada mais nada menos do que um meio de comunicação!

Se vc pegar um papel de pão, e rabiscar ele usando GML e a outra pessoa entender o que deve ser feito, então para que uma documentação de 100 folhas com margens para falsas interpretações?

No final, a informação foi transmitida do mesmo jeito, com mais eficiência, e com menor possibilidade de que o recptor tenha entendido errado a mensagem passada!

Bom pessoal, gostaria de manter a discussao dentro do contexto de organizacao e documentacao de ideias. Nao encarem de maneira rispida o que colocarei abaixo, estou apenas pedindo para que voces me provem do ponto de vista tecnico que "documentacao nao serve pra nada mesmo", afinal, estamos em um forum que discute Padroes de Projeto, e algumas das mensagens anteriores me causaram duvidas se realmente as pessoas usam Padroes de Projeto (projeto como um todo, nao apenas sentar na frente do micro e programar), principalmente o lance do "anotar em papel"!

Sinceramente, este negocio de "GML e papel de pao" me parece uma conversa amadora do ponto de vista academico. Tudo bem que tenha gente que desenvolva software anotando tudo em papel e entregando a tarefa para outra pessoa fazer.

Mas vejam que neste caso, situacoes como o "desenvolvedor-mor" que sai da empresa, ou que "nao tem didatica" pra explicar para o "desenvolvedor-JR", ou que o software seja vendido para outra empresa que ira agrega-lo a algo maior, etc, esta "explicacao boca-a-boca ou Net-a-Net ou papel-a-vista", parece uma maneira "no minimo estranha" de se conduzir um projeto.

Ahhh, e gostaria de saber se alguem tem resposta pra minha pergunta sobre se existe uma Ferramenta CASE light que citei anteriormente.

Sobre a ferramenta, de graça eu não conheço, paga Magic Draw e Rose, pelo menos.

Sorbe academia, se você pegar os textos clássicos e os textos modernos que servem de base para tudo (Fowler, Beck, Robert Martin, Arthur Riel, Meyer, Rod Johnson,...) vai encontrar exatamente essa abordagem.

Caro Philip,

Eu estou lendo o material sobre AM.
Contudo, gostaria da sua opiniao sobre diagramar ou nao diagramar, tanto do ponto de vista academico quanto do ponto de vista pratico/comercial. Voce segue a mesma opiniao de outros colegas que disseram que o negocio é manter codigo organizado, usar qualquer (ate anotacoes em papel) para passar informacoes para uma equipe de desenvolvimento, e esquecer que existe UML/DER/DFD/Dicionarizacao/etc.

Eu trabalho com desenvolvimento ha 16 anos e ate comecar com C++ e depois Java, sempre trabalhei com linguagens estruturadas e BDs relacionais. Sendo assim, eu me acostumei a documentar pelo menos o BD atraves do DER. Quando comecei a usar Java em 1999 e depois estudar UML, mesmo assim continuei documentando o BD em DER e nada mais de diagramas. Portanto, eu ainda nao me convenci totalmente da praticidade do uso da UML, mas ao mesmo tempo, acho que o Diagrama de Classes é uma ferramenta importante durante o ciclo de vida de desenvolvimento, e por isso gostaria de "migrar" do DER para o DC. Contudo, vejo limitacoes praticas nas ferramentas CASE UML do ponto de vista de geracao de classes Java e scripts SQL. Portanto, continuo documentando o DER do BD, e acho muito facil de mante-lo atualizado. Gostaria de ter o mesmo mas na visao OO do DC. Neste sentido que gostaria de evoluir estas discussoes.

Olá,

edilmar wrote:
Contudo, gostaria da sua opiniao sobre diagramar ou nao diagramar, tanto do ponto de vista academico quanto do ponto de vista pratico/comercial. Voce segue a mesma opiniao de outros colegas que disseram que o negocio é manter codigo organizado, usar qualquer (ate anotacoes em papel) para passar informacoes para uma equipe de desenvolvimento, e esquecer que existe UML/DER/DFD/Dicionarizacao/etc.

O pessoal exagerou um pouco.

A tendência hpje é um desenvolvimento ágil. Neste modelo existe sim documentação, mas ela não se manifesta apenas como especificaçõe se diagramas.

O grande problema de especificações é que elas não refletem automaticamente o status do projeto.

Se uma especificação *completa* é feita antes da implementação começar, em pouquíssimos casos ela estará válida após o processo. Aí vem aquele papo de "depois eu atualizo" que eu nunca vi funcionar.

A proposta é adota diagramas simples apenas para comunicação interna e documentar seu projeto de formas mais ligadas ao código.

Existe documentação, ela só é um pouco diferente do normal.

Eu sei, soa estranho, cotnraditório..um passo apra trás, mas não é bem assim. Se você se continuar lendo, pode acreditar que nunca aplicaria uma metodologia agil 100%, mas eu tenho certeza que os princípios vão modificar o modo que você enxerga o software pelo menos um poquinho

Artigos bons de pessoas conceituadas:
http://www.martinfowler.com/articles/newMethodology.html
http://www.objectmentor.com/resources/articleIndex

E livros recomendados:
Agile Software Development, Principles, Patterns, and Practices
Refactoring
Extreme Programming Explained : Embrace Change

edilmar wrote:
de Classes é uma ferramenta importante durante o ciclo de vida de desenvolvimento, e por isso gostaria de "migrar" do DER para o DC. Contudo, vejo limitacoes praticas nas ferramentas CASE UML do ponto de vista de geracao de classes Java e scripts SQL. Portanto, continuo documentando o DER do BD, e acho muito facil de mante-lo atualizado. Gostaria de ter o mesmo mas na visao OO do DC. Neste sentido que gostaria de evoluir estas discussoes.

Uma rpemissa básica: nunca coloque num docuemnto um diagrama que pdoe ser gerado automaticamente a qualquer momento (e baseado no código mais atualizado).

Notícias, artigos e o maior fórum brasileiro sobre Java