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

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

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.

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:

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.

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?

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

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á,

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:

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

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

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.

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?

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

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

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.

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.

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?

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.

Bom…

Acho que isso é uma coisa que precisa ser melhor estudado e pesquisado. Por uma lado, existe um grupo de pesquisa dentro de linguagens formais que busca a criação de aplicações automaticamente através de especificação bastante precisa. Por outro, existe uma tendência de padronização de processos onde a integração/interação de várias aplicações, pessoas, e demais entidades seria gerida por uma ferramenta de BPM através da descrição (documentação) dos modelos de negócios. Ainda, uma outra tendência é padronizar os processos de construção de software com o objetivo de se conseguir qualidade e transparência, através de, entre outras coisas, uso padronizado de documentação. Etc, etc, etc…
E nesse zoológico todo tem o pessoal da metodologia Agile, que não propõe a extinsão da documentação, mas seu uso de forma mais racional. Então, a questão que PRECISA ser melhor estudada: o que é importante ser documentado, e quais artefatos levariam a uma “boa análise”, ou que seriam relevantes para os objetivos procurados pelo cliente.
Eu vejo o projeto Apache, Linux, etc … exemplo de como a documentação de projetos grandes podem ser leves e úteis. Também merecem ser analisados.
Finalmente, eu gostaria de deixar minha angústia registrada aqui por ser muitas vezes obrigado a ler DER, quando Diagrama de Classes de Objetos de Negócios seriam tão mais agradáveis!!!

“Agile” nao eh uma metodologia, eh uma qualidade de diversos processos de desenvolvimento, como XP e Scrum, e nao tem nada que diga que o uso de documentacao deve ser racional - o uso de documentacao simplesmente nao eh o foco, o foco eh desenvolver software, nao PDFs. Mas eu sou suspeito pra falar dessas coisas.

A sua angustia eh ter sido “obrigado” a ler um DER pq nao tinha ninguem no time que pudesse simplesmente te explicar como a coisa funciona (rabsicando em cima de um DER, talvez), nao? Nesse caso, se fosse um diagrama de classes, um hieroglifo ou uma tirinha do Dilbert, qual seria a diferenca?

cv:

A sua angustia eh ter sido “obrigado” a ler um DER pq nao tinha ninguem no time que pudesse simplesmente te explicar como a coisa funciona (rabsicando em cima de um DER, talvez), nao? Nesse caso, se fosse um diagrama de classes, um hieroglifo ou uma tirinha do Dilbert, qual seria a diferenca? :)

Ei, peraí, uma tirinha do Dilbert é completamente auto-explicativa :mrgreen:

cv:

A sua angustia eh ter sido “obrigado” a ler um DER pq nao tinha ninguem no time que pudesse simplesmente te explicar como a coisa funciona (rabsicando em cima de um DER, talvez), nao? Nesse caso, se fosse um diagrama de classes, um hieroglifo ou uma tirinha do Dilbert, qual seria a diferenca? :)

E tirando a tirinha do Dilbert, um milhão de vezes o diagrama de classes. Vou dar um exemplo: suponha que você comece a interessar por um projeto open-source de gerenciamento de hotéis (para você administrar sua rede hoteleira espalhada pela Europa <img src="//https://cdn.jsdelivr.net/gh/twitter/twemoji@14/assets/72x72/w.pngink.png?v=5" title=":wink:" class="emoji" alt=":wink:"> ). Você vai na página que explica como a aplicação funciona e … o que você gostaria de encotrar aqui ?

a) Tirinha do Dilbert

b) Diagrama de classes (de negócio);

c) Diagrama de Entidade de Relacionamento;

É óbvio que uma figura jogada de um diagrama de classes não serve como documentação, mas o que seria de mais fácil leitura ???

rodrigousp:

cv:

A sua angustia eh ter sido “obrigado” a ler um DER pq nao tinha ninguem no time que pudesse simplesmente te explicar como a coisa funciona (rabsicando em cima de um DER, talvez), nao? Nesse caso, se fosse um diagrama de classes, um hieroglifo ou uma tirinha do Dilbert, qual seria a diferenca? :)

A tirinha do Dilbert seria mais divertida

E tirando a tirinha do Dilbert, um milhão de vezes o diagrama de classes. Vou dar um exemplo: suponha que você comece a interessar por um projeto open-source de gerenciamento de hotéis (para você administrar sua rede hoteleira espalhada pela Europa <img src="//https://cdn.jsdelivr.net/gh/twitter/twemoji@14/assets/72x72/w.pngink.png?v=5" title=":wink:" class="emoji" alt=":wink:"> ). Você vai na página que explica como a aplicação funciona e … o que você gostaria de encotrar aqui ?

a) Tirinha do Dilbert

b) Diagrama de classes (de negócio);

c) Diagrama de Entidade de Relacionamento;

É óbvio que uma figura jogada de um diagrama de classes não serve como documentação, mas o que seria de mais fácil leitura ???

Depende, se o cara fez tudo usando .NET, usando RecordSets, a melhor maneira de se mostrar isso seria com um diagrama DER, cheio de “notes” por favor :mrgreen:

Um diagrama de classes seria mais interessante se os vários objetos fossem mais do que “carregadores de dados”, já que você provavelmente não vai colocar os “actions” da camada web em um diagrama de classes né.

E como o CV já disse, se tiver alguém pra lhe mostrar como a coisa funciona de verdade, pode até não ter nenhum dos dois. Ele dá umas rabiscadas, lhe diz a entidades importantes pra o seu trabalho, o que elas fazem e diz onde você pode pegar os fontes e gerar a documentação e ver os testes unitários.

oi edilmar, deixa primeiro te mostrar o cenário da empresa onde trabalho pra que fique claro o contexto:

• mais de 3000 funcionários - (isso só no Brazil);
• projetos CMM nível 3,4 e 5;
• worldwide;
• off shore (trabalho dos gringos terceiro pra países subdesenvolvidos);

A empresa é a número 2 em prestação de serviços em informática no mundo, tendo clientes gigantes.

Bem, agora vamos lá.

Pros nossos projetos a documentação é fundamental, não há tempo hábil pra treinamento qdo rolam mudanças de equipe (depois de 1 ano e meio no projeto nossos funcionários podem optar por mudar de projeto - havendo disponibilidade, claro) e isso é exigência pra projetos sob cmm ou sarbanes-oxley. Os projetos são bem grandes, as equipes mudam muito e ainda rolam mudanças de ferramentas e tecnologia constantemente.

A parte de processo e metodologia é muito bem definida (chega a ser burocrático - mas sabemos que não dá pra ficar sem).

Cada projeto passa por uma fase te tailoring para elencar os artefatos realmente necessários dentro de sua realidade e isso é feito iterativamente (temos uma metodologia própria, baseada no rup).

Nossa documentação tende a ser extensa, muito extensa.

Cada projeto tem suas próprias necessidades e não há como, nesse ambiente, forçar ferramentas específicas - nós sugerimos mas quem decide é o cliente. Pra vc ter uma idéia: alguns de nossos projetos usam rose, outros together, calliber, star team, outros posseidom e aí vai.

No meu projeto especificamente usamos rose, clearcase, clearquest, office e eclipse (a galera dos USA usa WSAD e WAS).

Estamos felizes! é claro que poria ser bem melhor:

• o rose podia se integrar com o eclipse (ou o WSAD) sem precisar do maldito XDE. O RAD podia se integrar com o rose (o RAD tá 10 mas ainda precisamos do rose - esqueci de dizer: alguns de nós lá estamos usando o RAD tb).

Isso tudo sem falar nos documentos para revisão.

É fato que essa parte de processo e metodologia melhorou muito, muito mesmo nos últimos 5 anos mas ainda estamos à caminho - ainda não chegamos lá. E sim, fazemos muita coisa na unha (isso pq qdo vc tenta usar alguma ferramenta ela ou faz errado, ou vc faz errado ou ainda não faz da forma que te atende).

Já pra projetos pequenos o próprio custo do processo acaba o inviabilizando (nosso menor cliente ainda é grande).

Woody

Eu achava UML inútil, ingenuamente. Estou tendo boas experiências com ele atualmente. Num projeto cheio de módulos, e cada módulo cheio de componentes e cada componente cheio de classes, fica difícil entender só lendo o código.

Ultimamente, quando alguém que usa o módulo que eu estou trabalhando faz um change request, o projetista, que tem total conhecimento da arquitetura do sistema, faz uma alteração em um documento UML (que esta versionado), coloca o diagrama de sequencia e de classes, do jeito que deve ficar o componente depois que eu implementar. Eu pego, leio o change request, vejo o documento e faço a mudança nescessário. É interessante que tem marquinhas no meu UML com o id da change request. Eu entrei esses dias no desenvolvimento deste módulo, com este sistema que nós estamos usando, eu consigo desenvolver sem precisar perder muito tempo com a arquiteture (já que se eu fizer alguma merda, tem testes unitários, de componetes, integrados e sistêmicos).

Claro que deve haver um comprometimento da equipe de atualizar os documentos. Esse negócio de o teste ser a documentação, bem, o próprio teste pode ficar desatualizado, e numa urgencia o cada da um maven.test.skip=true para compilar e mandar para o ambiente a mudança que ele fez em um componente.

Se o próprio teste vai ficar desatualizado, imagine como deve estar a sua documentação

Como vc mesmo disse, deve haver comprometimento da equipe em atualizar os documentos. A diferenca eh que testes automatizados te avisam quando estao desatualizados (pq eles falham).

Documento do Word ainda nao tem compilador, mas se vc quiser algo proximo disso, o Fit eh bacana.

Daniel Quirino Oliveira:

Se o próprio teste vai ficar desatualizado, imagine como deve estar a sua documentação ;)

Pior que nao!
Eh complicado eu ficar falando, mas tem um bom motivo para o teste estar desatualizado e a documetacao nao. Eh compreensivel.

O que é pais perigoso ficar desatualizado? Um teste que garante uma funcionalidade importante do sistema ou um documento que alguém só vai olhar quando todo o sistema parar de funcionar?

microfilo:

Daniel Quirino Oliveira:

Se o próprio teste vai ficar desatualizado, imagine como deve estar a sua documentação ;)

Pior que nao!
Eh complicado eu ficar falando, mas tem um bom motivo para o teste estar desatualizado e a documetacao nao. Eh compreensivel.

Testes podem muito bem ser compreensiveis - se os seus nao sao, ta na hora de corrigir isso ao inves de voltar pro Word.

Word? OpenOffice!

QUALQUER SEJA A MERDA DO PROCESSADOR DE TEXTO. Favor voltar pro assunto.

Em situações desesperadoras, críticas e inaceitáveis demoras, sim os testes estariam em primeiro plano, porém quando se quer entender e estudar o sistema, os testes não ajudariam muito.

Em situações desesperadoras, críticas e inaceitáveis demoras, sim os testes estariam em primeiro plano, porém quando se quer entender e estudar o sistema, os testes não ajudariam muito.

Ja tentou pra saber?

Em situações desesperadoras, críticas e inaceitáveis demoras, sim os testes estariam em primeiro plano, porém quando se quer entender e estudar o sistema, os testes não ajudariam muito.

Ja tentou pra saber? ;)
Testes não expressam os diagramas da uml ;), que alguns são essenciais pra se caso a equipe mude por exemplo, basta uma olhada na disposição dos elementos, para facilitar o entendimento, mas também os testes ajudam, claro, mas isso em segunda instância.

Você quer dizer que a principal documentação seriam os testes ? :roll:

Provavelmente sim. Não vejo como seria possível manter atualizados mais que os testes e - em se tratando de documentação tradicional - um diagrama geral para a arquitetura, a não ser que seja utilizado um processo extremamente rígido (o que pode ser ainda pior).

Andaram falando aí em engenharia reversa. Outro dia precisei disso e cadê ferramenta livre que entendesse os generics? Resultado: nenhuma associação reconhecida. Serviu só pra heranças, implementações e pra criar as caixinhas nos pacotes.