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

Programação Arquitetura
#21

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!!!

#22

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

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

#23

[quote=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? :)[/quote]

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

#24

[quote=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? :)[/quote]
A tirinha do Dilbert seria mais divertida :wink:

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

#25

[quote=rodrigousp][quote=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? :)[/quote]
A tirinha do Dilbert seria mais divertida :wink:

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 :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 ???
[/quote]

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.

#26

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

#27

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.

#28

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

#29

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.

#30

[quote=Daniel Quirino Oliveira]
Se o próprio teste vai ficar desatualizado, imagine como deve estar a sua documentação ;)[/quote]

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

#31

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?

#32

[quote=microfilo][quote=Daniel Quirino Oliveira]
Se o próprio teste vai ficar desatualizado, imagine como deve estar a sua documentação ;)[/quote]

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

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

#33

Word? OpenOffice! :slight_smile:

#34

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

#35

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.

#36

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

Ja tentou pra saber? :wink:

#37

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

Ja tentou pra saber? ;)[/quote]
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:

#38

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.

#39