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

Programação Arquitetura
#1

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,

#2
  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 :stuck_out_tongue: )

#3

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.

#4

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).

#5

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 :wink:

#6

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.

#7

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.

#8

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.

#9

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? :wink:

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:

[quote=edilmar]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.[/quote]

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.

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

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?

#10

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”?

#11

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!

#12

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.

#13

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.

#14

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.

#15

Olá,

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 :slight_smile:

Artigos bons de pessoas conceituadas:


http://www.objectmentor.com/resources/articleIndex

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

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).

#16

É só imaginar assim, você tem um diagrama de classes feito no papel que é extremamente simples, aí você começa a codificar e enquanto vai codificando e testando percebe que são necessários novos atributos, novas classes, novos um bocado de coisas.

Mas você não para de codificar e testar, continua trabalhando iterativamente, vendo os resultados. Aí, umas duas horas depois chega o seu chefe e diz, “me passa o seu diagrama de classes atual”. Você pega a sua ferramenta de UML, faz engenharia reversa de código e gera todo o seu diagrama de classes 100% atual com tudo o que você definiu, imprime e entrega pra ele!

Qual a diferença? Você não perdeu tempo desenhando o diagrama, porque ele pode ser gerado a qualquer momento, com garantia que ele é o mais atual possível. Uma das práticas comuns em métodos ágeis é não fazer manualmente o que pode ser altomatizado, se você pode gerar o seu diagrama de classes a qualquer momento com um clique do botão, pra quê vai ficar desenhando ele numa ferramenta pra depois codificar?

Até mesmo os outros diagramas podem ser gerados automaticamente. Por exemplo, se você tem um diagrama de caso de uso no Rose, pode “gerar” os diagramas de sequência e por aí vai. Aí vem uma pergunta, se um sai do outro (com uma ferramenta), é realmente necessário fazer os outros? Sim e não.

As vezes você tem uma ação muito complexa, cheia de estados, que seria melhor exemplificada usando um diagrama de estados. Nesse caso específico isso é necessário, vai me ajudar a facilitar a explicação do problema, mas na maioria dos casos, isso pode ser inferido facilmente. Por exemplo, pra um usuário acessar partes restritas de um sistema, ele tem que estar autorizado e autenticado, você vai criar um diagrama de estado pra mostrar isso em todos os casos, mesmo sendo possível inferir essa informação?

Sobre a documentação, como o Phillip e o CV já disseram, é só o que interessa. Pra que escrever uma coisa que eu sei que ninguém vai ler, pior ainda, pra que escrever uma coisa que eu nem sei pra que é que eu estou escrevendo!

Outra coisa não vamos confundir padrões de projeto com metodologias de software não, porque se for pra se fazer alguma relação, alguns dos mais importantes autores sobre padrões de projeto, como Erich Gamma (autor do clássico “Padrões de projeto”) e Martin Fowler (autor do também clássico PoEAA) são alguns dos maiores advogados de metodologias ágeis :mrgreen:

#17

Sobre essa história toda de documentação, após passar por diversas experiências diferentes (empresas pequenas e grandes, equipes competentes e incompetentes, documentação “cavalar” feita antes e minimalista feita depois, etc.), meu conselho - que assusta muita gente - é: só produza documentação que vai ser mantida atualizada todo tempo ou que possa ser relacionada exatamente ao código que documenta, i.e., em que instante do tempo, quais linhas de código foram documentadas etc. Aí vem a pergunta: mas isso não é muito extremista?

Um exemplo besta: suponhamos que você esteja tendo um problema no seu código e você perde um tempão pra descobrir o porquê, até ver que aquele método/regra de negócio que estava documentado de um jeito não é mais assim e isso que estava causando todo o problema. Alguma vez na sua vida você vai confiar em qualquer documentação desse projeto? Duvido. Vai ficar sempre com o pé atrás quando ler a documentação e vai acabar sempre dando uma olhada no código pra ver se o que está documentado é o que faz mesmo.

Pra piorar, um belo dia, você cai num problema parecido de novo e percebe algo pior: o código sofreu alterações sutis e como você leu a documentação, foi induzido na sua análise rápida a achar que o código realmente fazia o que a doc dizia. O que você faz depois disso? Nunca mais lê a documentação.

E aí, se você for ver o tempo que foi gasto para documentar tudo e manter atualizado até ali e a diferença de tempo entre ler a documentação e o código, vai ver que não vai valer a pena. Então, documentação só serve se estiver sempre atualizada ou se referindo exatamente, de forma inconfundível, ao que documenta (ex: código do dia x ou versão 1.x da classe y). Logo, só produza a documentação pra qual você consiga seguir a regra acima. Se isso é javadoc, especificação funcional, diagramas UML ou mesmo só o código fonte, vai depender de você e da sua equipe.

#18

Obrigado ao pessoal pelas últimas mensagens. Somente para fechar o tópico com um resumo de tudo:

Documentação pode ser útil de for mantida sempre atualizada. Isso parece óbvio, mas a chave aqui é ter uma ferramenta CASE inteligente que possa fazer a engenharia reversa decente das milhões de linhas de código implementadas após os Diagramas/Documentos/folhas de papel/etc iniciais de Análise, certo?

Neste caso, qual seria a sugestão de vocês? Rational Rose (paga) e nenhuma free?

E vocês não usam/consultam nem um “DER” para ver as tabelas e os relacionamentos do BDR? Pois pelo visto a idéia de fazer (ou gerar por engenharia reversa) o Diagrama de Classes não é usada pra nada mesmo, nem para consulta do projeto como um todo, certo?

#19

Pode ser util quando for mantida atualizada e for, errrrhm, util. A documentacao pode estar atualizadissima, mas se for so um diagrama de classes que o Eclipse/IDEA tornam redundante (pq eles ja tem visualizacoes de hierarquias, membros e colaboracoes entre classes), nao adianta muito ficar mantendo a doc :wink:

Um diagrama de classes que mostra os principais patterns aplicados, e como a arquitetura geral do sistema funciona eh legal, e geralmente nao precisa ser atualizado o tempo todo, mas eh o tipo de coisa que uma ferramenta CASE nao vai resolver pra vc. Nesse caso, eu volto a bater o peh na GML - todo mundo envolvido no projeto deveria conhecer a arquitetura geral do sistema, e deve ser capaz de explicar, com maior ou menor nivel de detalhe, todas as entidades envolvidas em alguma situacao. Nos story cards aqui, por exemplo, sempre tem um diagraminha simples mostrando como a coisa funciona, e a gente poe umas marquinhas vermelhas nas classes que estao com o test coverage baixo (indicando que eh necessario fazer testes pra elas antes de mexer). Funciona, e nao leva mais de 20 minutos pra entender um cartao desses e sair programando, mesmo que vc tenha entrado na equipe semana passada :wink:

Como eu disse, isso nao vale muito a pena pq as ferramentas CASE nao vao te dar a visao geral do sistema - so a local. Elas nao entendem ainda que aquele grupinho de classes dentro do pacote tal tem relacionamentos 80% similares com aqueles outros dois, e isso constitui um pattern tal. Entao, a menos que vc queira uma visao local do sistema, engenharia reversa de UML nao serve pra muita coisa.

Um DER, ao contrario de um diagrama de classes, nao sofre do problema de ‘localizacao’. Nesses casos, usar engenharia reversa funciona bem, e eu nao vejo pq nao perder um tempinho gerando documentacao dessa forma, nem que seja uma vez a cada final de iteracao.

#20

Que faça tanta mágica não tem não, nem o Rose faz :lol:

Você tem um ótimo motivo pra querer ter tanta documentação?

Antes de gerar qualquer documentação, é bom saber pra quê e por quanto tempo ela vai servir.

[quote=edilmar]E vocês não usam/consultam nem um “DER” para ver as tabelas e os relacionamentos do BDR? Pois pelo visto a idéia de fazer (ou gerar por engenharia reversa) o Diagrama de Classes não é usada pra nada mesmo, nem para consulta do projeto como um todo, certo?
[/quote]

O do BDR é tão simples quanto fazer engenharia reversa do diagrama de classes. Solta uma ferramenta lá e pronto, o MySQL mesmo tem o DbDesigner que quebra um galhão.