Atena Framework: Nova plataforma de desenvolvimento de sistemas do Ministério Público Federal

Olá

É interessante desde que ninguém por aí tenha a “brilhante” (*) idéia de engessar isto como aquela velha e tola ideía de “framework de referência” (**) como muitas consultorias de 3 letrinhas tentam fazer por aí.

Espero sinceramente que isto NÃO seja um “framework de referência” para ser usado em todos os projetos…

(*) é ironia mesmo

(**) eu concordo plenamente com o que foi dito na palestra do Paulo Silveira e Phillip Calçado no último JustJava sobre como é horrível a ideía de “framework de referência” (slide 50 do Bozo com a bomba na mão). No caso de empresas de Governo isto chega a ser até perigoso.

[]s
Luca

Luca:

como é horrível a ideía de “framework de referência” . No caso de empresas de Governo isto chega a ser até perigoso.

Você não faz idéia o quanto isso está se tornando rotina.
Só o que tem hoje são esses frameworks de referência e pra você conseguir montar a arquitetura que atende sua solução sem usá-los é sempre um parto. Eles são tidos como algo sagrado. E são empurrados como A SOLUÇÃO.

Pior que em geral eles se baseiam em struts, ejb, tiles, muito xml, às vezes uma pitada de VOBO…

Eu não participei da justjava… mas fiquei curioso, entendi mais ou menos mas vou fazer a pergunta completa: O que são frameworks de referência e porque são ruins?

Valeu!

Olá

1. Frameworks de referência são aqueles pacotes de tecnologias que mal ou bem deram certo em um projeto com determinadas características que o gerente quer seja adotado como padrão para todos os futuros projetos.

O gerente neste caso pensa igualzinho àquele prefeito de uma cidade da Virgínia/USA, que em 1800 e pouco, mandou fechar o departamento de patentes porque julgava que tudo que era necessário já tinha sido inventado.

2. É ruim por 2 motivos:

a) Não existem 2 projetos iguais com as mesmas características, mesmo considerando os mesmos ramos de negócios. Exemplo: um sistema de controle de estoque e faturamento tem características diferentes de um sistema de CRM que acompanhará as vendas e o faturamento.

b) Mesmo que existissem 2 projetos iguais, o que há de novidade no mundo pode significar grandes melhorias no modo como uma mesma coisa foi feita no passado. É tolice engessar o modo de fazer as coisas.

O engessamento é ruim porque até mesmo uma nova versão do que já era usado às vezes é proíbida para não quebrar o tal framework de referência. Comparem as versões do Spring ou do Hibernate e vejam quantas novidades mudaram o jeito de fazer antigo.

Sempre que conhecerem uma empresa que adota o tal “framework de referência”, lembrem-se do prefeito da cidadezinha da Virgínia.

Acho que não deve ser o caso de quem postou a mensagem inicial mas no caso de empresas de Governo, adotar um “framework de referência” é perigoso porque pode atrelar futuras compras a um determinado grupo capaz de fornecer coisas com determinado perfil.

[]s
Luca

Oi Luca, valeu!

Agora uma dúvida, um framework o qual você está em todo projeto tendo a possibilidade de melhora-lo, mudar uma coisa ou outra, mas que vc usou ele apenas da idéia da concepção para não refazer a roda por exemplo na hora de abrir conexões, formulários, etc. vc usou ele como uma referência e mudou para aplicar a sua necessidade, é considerado um framework de referência ou apenas um que vc usou na concepção para não reinventar rodas?

Abs!

Olá

O erro não é definir um grupo de tecnologias para desenvolver um determinado projeto. Isto todo mundo deve fazer. O errado é fixar este grupo de tecnologias como algo que sirva para tudo no futuro.

[]s
Luca

Minhas considerações sobre o tema (com alterações):

O Atena Framework foi resultado do processo natural de desenvolvimento de sistemas do Ministério Público Federal, e de preocupações com reúso. Ele foi gerado para facilitar a criação de sistemas com as tecnologias utilizadas pelo MPF, incorporando funcionalidades que resolvem questões recorrentes em nosso processo de desenvolvimento (como disse o balancin, para não reinventar a roda).

Considero que ter um framework de referência (ou frameworks) é positivo em vários sentidos:

a) O framework oferece uma solução já amplamente testada
b) Os sistemas desenvolvidos terão códigos parecidos
c) Manutenção e documentação facilitada
d) Melhor aproveitamento de recursos para capacitação e treinamentos
e) Maior produtividade da equipe
f) Menor cursto de produção
e muitos outros…

No entanto, compreendo a preocupação do Luca de não engessar o processo de desenvolvimento nem a criatividade dos programadores. A intenção não é essa! Se o Atena não atender aos requisitos dos usuários, outra solução deverá ser pesquisada. Mas se atender, é melhor que seja desenvolvido com ele!

Além do mais, o Atena é um framework em constante evolução (já são 4 versões em 3 anos). Os feedbacks dos desenvolvedores são insumos para as novas versões. Assim, não existem amarras contra mudanças. Só nos preocupamos com mudanças muito radicais em curtos espaços de tempo.

E mais uma vez: O Atena não impõe qualquer limite às tecnologias adotadas, Struts 2, Velocity, EJB 3 e JPA. Ele apenas expande suas possibilidades!

[]s
Godoi

Poutz, só essa pretensão já deveria ser motivo suficiente pra abortar o projeto.

Veja, eu não costumo ter posturas muito radicais, mas quando se trata de fixar padrões a coisa é um pouco diferente. Eu acho que vocês simplesmente ignoraram a existência de qualquer desvantagem. E veja os pontos positivos: “maior”, “melhor”, “facilitada”. Deixe-me por isto em termos que qualquer leigo entenderia: chute.

Ao meu ver, o que está acontecendo é a clássica situação em que se tem um problema, gerado pelas pessoas: código pouco organizado, mal documentado, repetitivo. E se tenta usar um software (no caso, o framework) como solução. O resultado dessa mistura é bastante óbvio: dois problemas.

Se o código já é mal documentado, difícil de manter, se a produtividade é baixa ou os sistemas são pouco testados, a adição de mais um framework não vai ajudar, ainda mais um desenvolvido internamente. Simples assim.

Vale a pena a leitura (onde o Joel escreve “methodology”, podem ler “framework desenvolvido internamente” que o efeito é o mesmo).

joelonsofware:

…so Youthful Programmer starts creating rules and procedures that are meant to make more consistent results. Over the years, the rule book grows and grows. Soon it’s a six-volume manual called The Methodology.

After a few dozen years, Youthful Programmer is now a Huge Incompetent IT Consultant with a capital-M-methodology and a lot of people who blindly obey the Methodology, even when it doesn’t seem to be working, because they have no bloody idea whatsoever what else to do, and they’re not really talented programmers – they’re just well-meaning Poli Sci majors who attended the six-week course.

http://www.joelonsoftware.com/articles/fog0000000024.html

[]s
-bruno

Jonatas

Em breve farei parte do quadro de servidores do MPU (Técnico em Informática - SC). Tenho algumas dúvidas quanto ao Atena.

1 - Qual o objetivo de criar componentes dinamicamente (Pagina, TabelaPaginada, etc) se poderiam ter sido utilizadas tags dos Struts ou componentes do JSF ?
2 - O Atena já esta sendo utilizado pelo MPF ?
3 - Qual a vantagem de se utilizar Ajax sem API’s externas ? API’S internas podem evoluir menos que as externas !!!

Abraço,

Frederico

Jonatas,

O Framework será aberto para contribuições da comunidade ?

Primeiro o mais fácil: O Atena está disponível no sourceforge e encontra-se aberto à contribuições. Aliás, por favor, contribuam!

Consulte http://atena.mpf.gov.br e http://sourceforge.net/projects/atena-framework

Jonatas,

Os projetos Atena MPF e Atena SourceForge serão integrados ou serão desenvolvidos paralelamente ?

Atualmente as tarefas estão no Jira do MPF elas serão migradas para o SF ?

Os fontes estão disponíveis através de cvs ou svn ?

[]'s

Fred

Fre_d,

O projeto de ambos os sites é o mesmo. No site Atena MPF encontra-se a documentação e o controle de mudanças. No site Atena SourceForge, as distribuições.

Estamos preparando o ambiente para disponibilizar o CVS. Ele será hospedado no site Atena MPF por questões de velocidade de acesso e conveniência para o MPF.

Até lá, pode-se obter os fontes compactados no SourceForge.

[]s
Godoi

Caro bzanchet,

Veja bem: ter um framework de referência e estar limitado a ele são coisas bem diferentes!

Antes de mais nada, é preciso entender que o Atena foi concebido para resolver o problema do desenvolvimento de sistemas corporativos do Ministério Público Federal, ou seja, para uma situação bem específica. O projeto foi publicado porque acreditamos que os nossos problemas possam ser semelhantes aos de outras empresas e órgãos.

Mas isso não quer dizer que ele resolva a todos os problemas nem que seja aplicável a todas as empresas. Por exemplo, uma “software house” provavelmente teria que utilizar as mais recentes tecnologias do mercado ou aquelas solicitadas por clientes. Esse não é o caso do MPF!

No MPF, os sistemas corporativos possuem quase todos os mesmos requisitos não funcionais (podendo variar em escalabilidade). O desenvolvimento de sistemas não é a atividade-fim do órgão para justificar um alto investimento em produção. O corpo técnico não é grande o suficiente para manter equipes especialistas em nichos de tecnologia. Um desenvolvedor deve ser capaz de manter códigos criados por outros. Cada vez que se adota uma nova tecnologia, deve haver um processo nacional de capacitação das áreas de informática de todo o país. Etc.

Nossa meta nunca foi criar os mais modernos e tecnológicos sistemas de informação, mas criar sistemas eficientes de maneira produtiva. Por isso, o Atena é importante: ele aumenta a produtividade da equipe, reduz custos de capacitação, integra as equipes de informática, promove manutenibilidade, padroniza o código, etc.

Volto a dizer: isso não quer dizer que ele tenha que ser utilizado sempre! Depende do caso!

Longe de mim tentar te convencer, mas melhor que falar de teoria é falar de prática: nós já passamos por modelos de desenvolvimento “fuzzy”, onde cada sistema tem a cara (e as tecnologias) de quem o desenvolveu, sem documentação ou padronização, e sem que ninguém consiga dar suporte. Hoje, temos processos, tecnologias e ferramentas padronizadas, e posso garantir que estamos bem melhor!

Como diz o ditado: “a melhor solução é aquela que resolve”!

[]s
Godoi

Frederico, vamos lá:

O Atena possui uma camada de visão baseada no Velocity de tal forma que o desenvolvedor não precisa programar em HTML ou JavaScript. Assim, os códigos do Atena são puramente Java! Isso é interessante para evitar que se tenha que dominar diversas tecnologias, para uma maior padronização dos sistemas, para garantir a acessibilidade dos mesmos, para compatibilização dos códigos entre navegadores, etc.

Mas, existe uma razão maior: como você utiliza conceitos de orientação a objeto em páginas JSP ? Alguma vez você já estendeu uma página JSP ? Pois é, com o Atena, esses conceitos ganham sentido! É possível estender interfaces visuais, criar componentes de diversas granularidades, e se utilizar de abstrações como, por exemplo, de “Casos de Uso” (um componente que encapsula um conjunto de páginas e seus fluxos).

Por fim, a criação de novos componentes é muito simplificada, sem a necessidade de criação de tags nem descritores.

Sim, já o utilizamos em diversos projetos. Com a versão atual, dois projetos estão em processo de homologação e um em fase de desenvolvimento

A vantagem é que se pode tratar chamadas síncronas e assíncronas exatamente da mesma maneira! Além disso, a complexidade do Ajax é encapsulada pelos componentes visuais do Atena.

Com relação a evolução, a questão para nós não é a quantidade de recursos dessas API´s externas, mas como elas fazem o trabalho básico que precisamos. Além do mais, se uma determinada API for considerada essencial ao nosso processo de desenvolvimento, integramos ela!

[]s
Godoi

Jonatas,

Baixei os fontes e criei um projeto no Eclipse.

Ai vai algumas dicas:

Para facilitar a colaboração de interessatos disponibilize um projeto completo (fontes, libs, etc) ou como já comentei o cvs. Baixei os fontes e tive que ficar procurando as libs.

Vocês já utilizaram a ferramenta JDepend ou uma similar para verificar a dependência circular entre pacotes ?

Vou analizar melhor o projeto e se eu tiver mais dúvidas entro em contato.

[]'s

Fred

O CVS em breve estará disponibilizado. Note no SourceForge os projetos com extensão ZIP: eles contém os fontes já com as dependëncias (libs).

Estamos estudando a utilização do Maven para controlar as bibliotecas.

Vamos olhar o JDepend! Obrigado pela dica!

[]s
Godoi

Pra quem ja teve um tempinho pra olhar o codigo, como estao os testes unitarios/funcionais?

Baixei o arquivo atena4.zip duas vezes. Parece que está corrompido pois não consigo extrair os arquivos e ele só tem 2MB.

Muito interessante a iniciativa no MPF.

parabens Jonatas e sua equipe.

Eu tambem acho que ter um framework de referência e estar limitado a ele são coisas bem diferentes.
e acho que é muito importante ter um de referencia (por que ele é uma “REFERENCIA”)

mas já quase apanhei por isso então não voi entrar mais na discussão

sem querer ser preguiçoso, mas vamos la:

Você vão disponibilizar e ampliar a documentação?

quantas pessoas estão atualmente envolvidas no projeto?

só você do MPF é membro do GUJ? (para ajuda com duvidas :P)

(com alterações)

Temos um projeto em fase de homologação para os facilitar a criação de testes unitários para as aplicações desenvolvidas com o Atena. Em breve será disponibilizado.

[]s
Godoi

fre_d:

Baixei o arquivo atena4.zip duas vezes. Parece que está corrompido pois não consigo extrair os arquivos e ele só tem 2MB.

Vamos verificar e se for o caso copiá-lo novamente. Valeu pela dica!

[]s
Godoi

Duran, obrigado pelas considerações.

Sim, a idéia é evoluir sempre a documentação. Estamos inclusive desenvolvendo um livro sobre o Atena.

Hoje a equipe de arquitetura da Procuradoria Geral da República possui 6 pessoas. Mas entre contribuidores e desenvolvedores são muito mais.

Atualmente, acho que sim! Mas estamos criando um email (não sei se já ficou pronto!) que divulgaremos para facilitar a comunicação com a equipe.

[]s
Godoi

Temos um projeto em fase de homologação para os testes unitários. Em breve será disponibilizado.

[]s
Godoi

O projeto é para desenvolver usando TDD ou para criar testes depois do código pronto?

Pronto, já vão cair de porrada em cima do cara por conta dos testes…

Eu apenas perguntei por curiosidade pq conheço um pessoal que trabalha no MP e provavelmente vai usar o framework, isso é “cair de porrada” ?

(com alterações) O objetivo é TDD em todos os projetos a desenvolver! O Atena, infelizmente, não foi desenvolvido com essa prática.

[]s
Godoi

Não foi pra você meu caro mueller.

[email removido:

]O objetivo é TDD! Como disse, o projeto está em fase de homologação.

[]s
Godoi

TDD, mas o framework não está pronto ??

o atena parece bacana, parabéns!

Tambem fiquei boiando… o que esta em fase de homologacao? Os testes unitarios do Atena em si? O framework de testes unitarios que o Atena disponibiliza? O que eh e como funciona esse processo de homologacao?

Acredito que eles vão utilizar TDD daqui pra frente… mesmo pronto o framework deve continuar evoluindo…
IMHO se tivesse utilizado TDD desde o início seria muito melhor

Para quem não teve tempo de olhar o código as bibliotecas referenciadas são:

javax.persistence
javax.activation
javax.mail
Apache Struts2 (ognl, xwork, etc…)
Apache Lucene
Apache Commons (Lang, Logging, Digester, Validator, BeanUtils, Collections)
Apache Velocity
Spring Web
JFree
cglib

Mais alguma ??

(com alterações)

nbluis:

[email removido:

]O objetivo é TDD! Como disse, o projeto está em fase de homologação.

[]s
Godoi

TDD, mas o framework não está pronto ??

O Atena está pronto! O projeto para facilitar os testes unitários dos aplicativos desenvolvidos com o Atena é que está em fase de homologação.

[]s
Godoi

…

O atena está pronto. Os testes unitários é que estão em homologação.

[]s
Godoi
Tudo bem sobre os testes unitários, mas nada de TDD.

Os testes estão sendo homologados?

(com alterações)

pcalcado:

[email removido:

]
O atena está pronto. Os testes unitários é que estão em homologação.

Os testes estão sendo homologados?

Vamos lá: Foi criado recentemente um projeto para facilitar a criação de testes de sistemas desenvolvidos com o Atena, e incentivar o TDD. Algo como classes helpers, que podem ou não ser estendidas para isso. Isso para permitir testes de execução dos aplicativos fora de um container web. Essa estrutura é que está em homologação. Em breve, estará disponível.

E qual o problema do JUnit? O framework não se baseia em POJOs?

Sim, mas para simular a execução dos aplicativos fora de um container web é preciso de classes auxiliares. Por isso, usamos classes de TestCases e Mocks.

O MockStrutsTestCase é um Mock para Struts 1.x que não se baseia em POJOs já que suas Actions têm que estender classes do framework. O Struts 2/WebWork acabou com este grande problema adotando POJOs para as Actions, que é algo bem comum em frameworks web como VRaptor, Spring MVC e todos os outros 3423524 projetos open-source.

Não sei há quanto tempo o framework criado pelo órgão público existe, se existir desde 2002-2003 realmente a cultura da época não previa frameworks com POJOs mas há uns bons 4 anos que isso é padrão. A necessidade de um framework para testes do framework é um dos problemas em adotar uma estratégia que obriga classes da aplicação a estender ou implementar classes e interfaces do framework. Sugiro que os autores do mesmo dêem uma olhada no que o mercado vêm fazendo e o porque do uso de POJOs onde existe regra de negócio/aplicação ter se tornado matéria quase que obrigatória para frameworks de todos os níveis.

(com alterações)

pcalcado,

Todos os componentes do Atena são POJOs, desde actions, classes de visão, EJBs, etc.

Para a criação de testes unitários com a aplicação em execução dentro de um container web, nenhum código adicional é requerido: basta o JUnit.

No entanto, para simular a execução da aplicação em um container, sem utilizar um, uma certa infraestrutura é necessária.

Não sei se deu para entender. Parte dos testes são realizados com o JUnit, outra parte com a estrutura criada.

O engraçado é que quando se trata de qualquer coisa Java, o termo usado é ‘engessado’ e todo mundo odeia, enquanto que quando se fala sobre Rails, o termo usado é ‘opinionated’ e todo mundo adora.

Então acho que o problema é o conceito de testes unitários. testes unitários não podem depender de um container para funcionar, do contrário eles não são unitários mas sim de integração.

Para ser um teste unitário eu devo poder instanciar a action (ou seu equivalente), chamar seus métodos e verificar o comportamento esperado sem depender de containers. Se as classes não podem ser testadas desta maneira simples não é um POJO já que depende da infra-estrutura. Como citei o Struts 1 era assim mas há muito tempo que os frameworks web não possuem mais essas limitações exatamente porque o modelo de programar em Java EE evoluiu visando maior qualidade e flexibilidade.

Para persistência outra técnica utilizada é a divisão em Camadas. Se você divide seu sistema em Camadas ele vai isolar as classes que de fato dependem do banco de dados e você consegue criar mocks para estas classes tranquilamente.

Ahm?

Ahm?

Calma, calma, não é nada pessoal. Na verdade, nem sequer é específico a este framework em questão.

É que às vezes eu acho engraçado que as pessoas dão piti quando se fala em estabelecer uma arquitetura ‘default’ para um determinado framework Java (nome de pacote padrao pra classes de visão, controllers e entidades, tem que ter tal anotação ou implementar tal interface, tem que seguir determinada convenção de nomeclatura, etc.), mas quando se trata do Rails (que possui diretórios padrão pra views, controllers e entidades, vc tem que estender determinadas classes, tem que seguir determinada convenção de nomeclatura, etc.), todo mundo acha lindo, dizem que isso vai destruir o Java, blábláblá.

De novo, não estou dizendo que esse Atena é um equivalente ao Rails pra Java (longe disso!), somente um comentário (genérico) sobre algo que eu tenho observado por aí.

Rails possui uma arquitetura padrão a ser utilizada para projetos com algumas características específicas. Se você não está no cenário adequado ou você usa plugins, ou muda o framework ou usa uma coisa mais apropriada.

uma coisa é definir um framework/arquitetura que é muito boa utilizada num cenário X ou Y, outra coisa é definir uma arquitetura para ser utilizada em todos os projetos, não importa do que se trata. Se um MPU ou alguma empresa adotar Rails como arquitetura de referência vai ser criticado da mesma forma: arquiteturas de referência, caseiras ou não, são o extremo oposto de boas arquiteturas.

Só estamos criando ferramentas para que os desenvolvedores possam testar seus códigos. Se não for preciso porque são POJOs, muito bem!

Só por curiosidade, como é a boa arquitetura ?

Olá

Me antecipo na resposta óbvia: depende do projeto.

Perguntas:

1. Todos os projetos de vocês são iguais e de mesmo porte?
2. Vocês vão exigis dos fornecedores que usem o framework de vocês?
3. Como pretendem lidar com as mudanças de versões. Por exemplo: a próxima versão do JPA deverá incluir Criteria. Poderá ser usado?

[]s
Luca

O primeiro critério é que o cenário seja analisado e uma arquitetura escolhida a partir dele, não a existência de uma arquitetura genérica. Pode ser a mesma arquitetura utilizada em outros projetos sem nenhuma mudança mas cada situação deve ser analisada.

O segundo critério é observar o que já foi criado pela indústria em termos de software, de prática e teoria e não reinventar a roda ou, caso seja necessário reinventar, que se faça seguindo princípios de qualidade da indústria.

O terceiro e tão importante quanto é que a arquitetura deve ser testável e executável.

Ok, até aqui concordamos. Mas no que se baseia essa decisão ?

Cara dei uma olhada na documentação do framework.

Parece que ele é show hein!

Olá

Poderia responder que se baseia entre a qualidade de uma decisão tomada por um ser humano ao invés da escolha automática de uma máquina. Mas não vou fazê-lo.

Responderei de outro modo: não existe arquitetura boa ou ruim porque ninguém compra arquitetura. O cliente compra sistemas e este sim é baseado em alguma arquitetura. Se o sistema funcionar bem dentro dos requisitos então dane-se o que tem por dentro.

Mas em contrapartida, quando o desenvolvedor inicia o desenvolvimento do sistema, se lhe é imposto que ele pode escolher todas as cores desde que seja preto, pode ser que se esteja ganhando muito tempo abreviando a escolha mas o resultado final também pode ser prejudicado.

Entenda que NÃO estou criticando seu framework que nem conheço. Sei que muitos daqui não se interessarão por ele enquanto não tiver testes unitários mas isto não quer dizer que ele seja ruim, apenas que ainda não é confiável.

O que eu criticarei é se ele for engessado tal como já expliquei antes. Se está bom para vocês, façam bom proveito mas não queiram que eu seja igual ao prefeito daquela cidade da Virgínia.

[]s
Luca

Eu dei uma olhada na parte de validação, que é a primeira coisa que eu olho em qualquer framework, por ser o básico do básico de todo projeto web.

http://atena.mpf.gov.br/confluence/pages/viewpage.action?pageId=884816

Não entendi muito bem, pois há 3 interfaces diferentes com vários métodos.

Dá para usar a validação como filtro/interceptor ou só atrelando ela a Action?

Como eu construo minha propria regra de validação, por exemplo para validar se o campo segue a regex ^[A-Z]+\d\d\d\d$ ?

O que eu defendo é que se alguém nessa altura do campeonato vai querer aprender yet another framework web in Java, então esse framework terá que ser o mais simples possível, idiot-proof, com uma documentação clara e objetiva, exemplos, etc.

Se o cara achar só um pouquinho complicado, engessado, obscuro, complexo, então com certeza ele vai abandonar e voltar para o Struts ou qualquer outra coisa da moda…

Eu vi que vc fez a validação tratar ao mesmo tempo a validação na parte do cliente e na parte do servidor. Bom, isso é mais poderoso mas tb muito mais complexo de o cara entender. Eu preferiria separar isso, primeiro porque nem todo mundo vai querer/precisar fazer a validação no cliente também e segundo porque facilita para um mero mortal entender.

De novo caímos no objetivo do framework. Ele quer ser usado por vários pessoas de todos os cantos e com todos os tipos de necessidades? Ou ele tem um target de projeto e comunidade específicos?

Algumas considerações:

Primeiro é necessário definir bem o conceito de arquitetura para que não se confunda com o de framework. Esses conceitos podem parecer semelhantes mas são muito diferentes! Também é importante conhecer como as decisões de escolha das “arquiteturas” são conduzidas para que se possa falar a respeito.

Então o fato de se utilizar a mesma “arquitetura” em mais de um projeto pode não ser ruim ? Hummm.

Os frameworks utilizados pelo Atena estão mesmo defasados ?

Então reúso é bom ?

pcalcado:

O terceiro e tão importante quanto é que a arquitetura deve ser testável e executável.

Como disse, os componentes do Atena são todos POJOs.

Luca:

Olá

Me antecipo na resposta óbvia: depende do projeto.

Perguntas:

1. Todos os projetos de vocês são iguais e de mesmo porte?
2. Vocês vão exigis dos fornecedores que usem o framework de vocês?
3. Como pretendem lidar com as mudanças de versões. Por exemplo: a próxima versão do JPA deverá incluir Criteria. Poderá ser usado?

[]s
Luca

É a famosa bala de prata neh Luca…

]['s

Ainda sobre validacoes, vi que estão usando o WebWork ou Strtuts 2 da na mesma. Estão usando a validacao dele? Se não estao existe algum motivo? Pra mim é um sistema de validacao muito bom, da pra fazer validacao ajax, client ou server facil.

]['s

Um framework faz parte da arquitetura então ele influencia nela. Não há como impor o uso de um framework e criar boas -ou razoáveis- arquiteturas para todos os projetos.

Logo…? Onde você quer chegar? Onde eu falei que reuso é ruim ou algo do tipo? Uma coisa é ter um objetivo nobre, outra coisa é atingi-lo.

A arquitetura dele está defasada. Até agora eu só vi código de vocês nos tutoriais então não sei o que usam por baixo além de JPA mas a falta de testabilidade fora do container é um problema, e isso deriva do código que foi criado pelo framework de fato, o resto é JPA.

Ainda usando JPA, pelo menos no tutorial, vemos uma classe de negócios (o que vocês chama de EJB) que segundo o mesmo “EJBs representam as classes de negócio propriamente ditas. O EJB é a classe que armazena os códigos negociais e que possui a lógica de armazenamento e de consulta ao banco de dados.” e uma classe de dados, que vocês chama de Entity que segundo a documentação “Quando o objetivo for o desenvolvimento da versão real do sistema, sempre se começa a codificar pelas entidades de negócio. Essas entidades representam as tabelas do banco de dados.”. procure sobre BO/VO e você verá os problemas disso.

Basicamente vocês pegaram o Struts 2 e puseram a pior limitação do Struts 1, que é a dependência do container, e pegaram o EJB 3 e transformaram em EJB 2.x, colocando lógica em Session Beans e dados em Entity Beans. Sim, a arquitetura está defasada. Alguns anos. Por isso que nos últimos posts eu sugeri que lesse sobre outras arquiteturas e visse o que a indústria está fazendo.

[email removido:

]

Como disse, os componentes do Atena são todos POJOs.

Não, não são. Eles podem não estender ou implementar interfaces mas não podem ser utilizados fora de um container, como você mesmo disse acima.

Para evitar maiores discussões:

1. A definição da arquitetura dos projetos do MPF é realizada baseada em critérios técnicos, não políticos.

2. O Atena é resultado de nossas experiências (somente nossas) no desenvolvimento de sistemas; ele é a consequência natural desse processo, não a causa.

3. O Atena não foi projetado para atender a todos os casos, mas para circunstâncias bem específicas do MPF.

4. As tecnologias adotadas pelo Atena podem não ser as mais modernas do mercado; isso não é fundamental para nós. O importante é ter resultado comprovado e pessoal qualificado para utilizá-las.

5. Ter um framework de referência é importante para nós (pode não ser para mais ninguém) porque traz consequências positivas para o nosso processo de desenvolvimento. Não falo de teoria, falo de prática.

6. Muitas das decisões que foram tomadas no Atena podem não ser as melhores (até por isso que estamos na 4a. versão), mas foram as melhores para a equipe do projeto naquele momento.

Enfim, ninguém está querendo dizer que o Atena é melhor do que nada. Só, humildemente acho, que ele tem idéias interessantes.

[]s a todos

Tem idéias interessante sim, ainda que eu não tenha visto tecnicamente tem a política de manter o código disponível. Isso é importante porque todos aqui somos investidores nesta plataforma tecnológica porque pagamos impostos e queremos que ela seja o melhor. O que mais me preocupa é dinheiro público sendo gasto para reinventar a roda mais uma vez novamente de novo, mas até aí esse não é o único caso.

De qualquer modo, como técnico e contribuinte sugiro novamente a leitura de alguns bons livros sobre arquitetura e design de projetos para entender o que há de errado no framework (ou na idéia de um framework para os projetos em si). Algumas indicações:

Mas vamos às considerações técnicas.

1. Sobre as tecnologias abordadas

Veja, o framework Atena não define a arquitetura que será utilizada. Você pode usar EJB ou não, você pode usar JPA ou não, você pode usar Velocity ou não, você pode ter camadas a mais ou a menos, etc. A única coisa obrigatória é o Struts 2. Mas apesar disso, o Atena propõe que se façam códigos compatíveis com a especificação EJB 3 para a camada de negócio; se o sistema será implantado ou não em um container EJB é uma segunda decisão.

2. Sobre a imposição de limitações do Struts 1 e do EJB 2

Isso é totalmente improcedente. Não existem tais limitações.

3. Sobre o desenvolvimento das entidades de negócio em primeiro lugar

Antes de mais nada, isso só tem sentido em relação à programação, não ao processo de desenvolvimento. Mas vamos lá, em nosso processo de desenvolvimento a equipe responsável pela implementação recebe da equipe de especificação o ambiente criado, a documentação do projeto, modelos e diagramas, os protótipos, e o banco de dados criado. A partir daí, a codificação tem sido iniciada justamente com a criação das entidades de negócio. Para nós, essa decisão faz sentido, mas gostaria de ouvir outras opiniões.

4. Sobre as interfaces de validação

A interface Validacao é a validação propriamente dita. A interface Validavel refere-se a um componente visual que pode ser alvo de validação. A interface Validante é aplicável , geralmente, a botões que podem ou não disparar a validação do formulário. E a interface Validador é aplicável ao formulário que contém os componentes a validar. Parece complexo, mas na verdade é bem simples.

5. Sobre a construção de regras de validação.

Para criar uma nova regra de validação, crie uma classe que implemente Validacao, adicione o código javascript de validação cliente à algum arquivo js do Skin em uso e pronto! Você já pode utilizá-la em suas interfaces visuais.

6. Sobre a unificação das regras de validação cliente e servidor.

A unificação dessas regras tem se mostrado mais fácil e produtivo do que quando eram separadas. Havendo necessidade de validação somente do lado servidor, basta não se fazer esse registro. Também nesse caso outras opiniões seriam interessantes.

7. Sobre a codificação das páginas em java

Esse, por mais que digam o contrário, é o maior barato! Deve-se entender bem como funciona a camada de visão para se emitir um julgamento. Essa separação dos templates do Velocity (com os códigos HTML) do código Java é que traz produtividade ao processo de desenvolvimento e permite abstrações diferentes das que estamos acostumadas. Quantas vezes vocês herdaram uma página JSP ?

8. Sobre a adição de scripts às páginas

Existem diversas formas de se adicionar scripts à página: a forma com o Maracuja falou (a não recomendada), por meio do componente Pagina, por meio de Skins (apontando para arquivos javascript), por meio de templates do Velocity, ou criando-se novos componentes que encapsulam esses scripts. Escolha a sua!

[]s
Godoi

E o que o framework faz, afinal? Lá no primeiro post desta thread temos mais da metade das características (ou funcionalidades) providas pelo mesmo que derivam de utilizar JPA e/ou o modelo de programação do tutorial. Se eu abrir mão do atena e utilizar apenas Struts 2 normalmente o que eu perco?

• Então porque você tem que criar um mock para realizar um simples teste unitário fora de um container? Struts 2 permite isso, Struts 1 não
• Releia o texto, não falei de limitações do EJB 2.x mas dos problemas gerados pelo modelo de programação e conforme citei trechos do tutorial sim, eles são sugeridos.

Isso é bem ruim!

Antes de mais nada eu sugeriria que já que estão utilizando uma linguagem orientada a objetos utilizassem OO e não programação procedural (programação procedural separa dados e lógica, programação OO os une).

Sobre o processo de desenvolvimento que você descreveu ele é o processo waterfall, desacreditado há mais de vinte anos (inclusive pelo seu criador). Procure ler sobre modelo iterativo incremental de desenvolvimento, especialmente com vertentes ágeis para entender o que o mercado tem feito nas últimas décadas.

Existe uma escola que acha que isso é bom, outra que não. Para mim depende do caso e exatamente este é o problema em termos uma arquitetura de referência como esta. Em vários momentos vai ser mais interessante utilizar uma linguagem especializada/DSL como JSTL, JSP, JSF ou o que for.

Resumindo: O framework como é, inclusive com os pontos que eu considero extremamente problemáticos, pode ser o ideal para algumas aplicações mas adotá-lo -ou a qualquer outro- como arquitetura de referência ou mesmo guideline é negar umas duas décadas de engenharia de software. E o ponto não é tecnologia moderna, vocês estão usando o sonho de muitos programadores presos a Struts 1.x e Java 1.3, o ponto é que creio que estão utilizando tecnologias modernas com mentalidade de tecnologias passadas.

(com alterações)

O Atena é uma extensão dos frameworks citados. Ele contém funcionalidades adicionais que podem ou não ser utilizadas. Por exemplo, há quem prefira manipular o arquivo “struts.xml” para fazer a configuração dos fluxos. No Atena, essa configuração é realizada por meio de anotações na action. Melhor do que eu falar dos recursos do Atena, é consultar a documentação do projeto.

Isso não é necessário para testes unitários, mas para testes de simulação da execução da aplicação em um container.

Mais uma vez você se refere a um processo que não conhece. O processo em questão é sim iterativo e incremental.

Para as outras, utilizamos outras tecnologias!

Eu consultei durante o dia e ainda estou confuso. Vou ter que procurar bastante para achar as funcionalidades pelo visto.

Estou confuso. Não foi bem isso que você disse antes:

Sim, mas para realizar testes nas actions é preciso criar um contexto de requisição. Por isso, usamos um Mock que cria esse contexto. Algo parecido com o MockStrutsTestCase.

É preciso ou não?

[email removido:

]Mais uma vez você se refere a um processo que não conhece. O processo em questão é sim iterativo e incremental.

Estou confuso novamente. Você descreveu o processo (até pediu opiniões!):

Onde entram as iterações e os incrementos no fluxo acima? Posso estar errado mas pelo que você descreveu os ‘implementadores’ recebem as especificações e diagramas dos ‘especificadores’.

[email removido:

]
Para as outras, utilizamos outras tecnologias!

Que bom.

Não. É opcional!

Descrevi uma sequencia de atividades, não disse que ela acontece apenas uma vez !!!

Que bom que concordamos em algo!

[]s
Godoi

Esse ping-pong deve estar meio cansativo para vcs dois…

O cara fez um framework legal, que foi bem sucedido no projeto dele, etc e tal. Fez uma documentação e soltou para quem quiser usar e ajudar. Parabéns pra ele nesse sentido…

Se é bom ou não, se segue as boas práticas ou não, se é moderno ou atrasado, se dá para usar em outros projetos ou não, se a validação é simples ou complicado, isso é um detalhe que o laissez-faire vai exclarecer muito bem.

Eu acredito que o livre mercado sempre fala mais alto que qualquer opinião técnica.

Bom, dado o nível de stress do debate fico por aqui. Espero que ao menos a lista de livros seja útil para alguém.

Voce pode citar algum exemplo onde usar mocks pra testes unitarios de actions/controllers facilita os testes?

Teoricamente, pode ter sua utilidade.

In a unit test, mock objects can simulate the behavior of complex, real (non-mock) objects and are therefore useful when a real object is difficult or impossible to incorporate into a unit test. If an object has any of the following characteristics, it may be useful to use a mock object in its place:

* supplies non-deterministic results (e.g. the current time or the current temperature);
* has states that are difficult to create or reproduce (e.g. a network error);
* is slow (e.g. a complete database, which would have to be initialized before the test);
* does not yet exist or may change behavior;
* would have to include information and methods exclusively for testing purposes (and not for its actual task).

eu também.

Cara, não olhei teu framework ainda, mas de qualquer forma parabéns!

Fazer algo OpenSource não é fácil.

Mas é desse tipo de coisa que estamos precisando, principalmente nos orgãos publicos brasileiros - transparencia e apoio a população ou comunidade.

Logico que o projeto de vocês se for levado a serio vai amadurecer e crescer.
Mas sobre as criticas, sempre existem é normal. Inclusive existem algumas criticas exageradas e que já ficaram batidas em tópicos como este (de novos projetos)… só ver o histórico… então faz parte.

Não há necessidade de citar, mas como brasileiro eu tenho vergonha de alguns comentários destrutivos que as vezes aparecem.
Mas os contrutivos e que tentaram mostrar outras visões (tirando o stress ou exageros) são excelentes - uteis como um brainstorm e ajudam a melhorar o teu framework.

Abraços,

Obrigado pelas manifestações de apoio.

Para esclarecer a questão dos testes: provavelmente nunca será preciso estender actions ou classes de negócio para a realização dos testes, apesar de ser teoricamente possível em alguns casos. O projeto a que fiz referência nos primeiros posts possui classes auxiliares, como TestCases, e mocks para a simulação da execução das aplicações fora de um container de servlet. De qualquer forma, são todos helpers que podem ou não ser utilizados. A analogia com o MockStrutsTestCase é que não foi feliz.

[]s a todos
Godoi

Oi Jônatas,

Eu vi o pessoal comentar que teve que correr atrás das libs que o projeto depende.

Eu sugiro que para resolver esse problema você considere o uso do Maven no projeto.

Uma pergunta: na decisão de framework MVC, não se pensou em usar outra coisa além do Struts , como Mentawai , VRaptor ou Spring MVC ?

Estamos considerando e provavelmente iremos usar.

boaglio:

Uma pergunta: na decisão de framework MVC, não se pensou em usar outra coisa além do Struts , como Mentawai , VRaptor ou Spring MVC ?

A decisão pelo Struts foi baseada nos recursos disponíveis no framework (obviamente), na experiência dos desenvolvedores do MPF, na mão de obra disponível no mercado e em casos de sucesso. Não faria sentido para nós usar uma tecnologia que ninguém conhecesse (aqui dentro, digo) ou que não fosse considerada madura o suficiente pela equipe. Mas isso não significa que utilizaremos o Struts sempre nem em todos os projetos. Apenas nos preocupamos que essas mudanças aconteçam de maneira responsável, gradual e com o menor impacto possível para a instituição.

[]s
Godoi

Olá. Desculpe a demora em responder. Vou evitar responder frase a frase, porque acho que escrever dessa forma dificulta a discussão.

Por favor, preste atenção nos seus argumentos: tu não gasta uma palavra defendendo o framework. Não fala de inovações técnicas, de novas abordagens, nada, nada. Fala só de padronização. Padronizar código, padronizar tecnologia, padronizar documentação.

Meu caro, para padronizar essas coisas, não é preciso escrever um framework. Discordas disso? Considerando este fato, resta mais algum argumento sustentando o uso do Atena? Eu não vejo nenhum.

Esse é exatamente o meu ponto. O problema estava nas pessoas, que desenvolviam sem documentação, sem padrões de código, sem tecnologias padronizadas. Logo, deveria-se tentar mudar as pessoas, para que padronizem as tecnologias, escrevam código documentado e seguindo os mesmos padrões. Tudo isso não implica nem justifica escrever um framework.

Que o Atena “aumenta a produtividade da equipe, reduz custos de capacitação, integra as equipes de informática, promove manutenibilidade, padroniza o código”… Vamos ser realistas: tudo aqui é chute puro e simples. Além do mais, pelo seu relato, não é nada que não pudesse ser obtido de forma muito menos custosa do que desenvolvendo o Atena. Por exemplo, via treinamento, seminários, adoção de práticas como TDD, integração contínua, uso de ferramentas como PMD, Checkstyle, etc!

Eu acredito quando dizes que impor o Atena resolveu alguns dos problemas. Mas a minha opinião é: foi uma solução muito mais onerosa do que poderia ter sido.

[]s
-bruno

Obrigado Jonatas por disponibilizar uma modelo de construção de sistemas, talvez agora eu possa ganhar velocidade e padronização na construção dos meus sistemas que consiste em cadastros, movimentações(1:N) e relatórios que ao meu ver é o comum da maioria dos desenvolvedores de sistemas para a grande fatia do mercado brasileiro que são as necessidades administrativas e comercias de uma empresa e que na maioria são pequenas empresas.

Mas eu juro que não vou ligar se e classe “XYZ” do Atena tem 153 linhas mesmo que alguns falem que deveria ter 152, juro que não vou ficar chateado que vcs tenham criado o Atena como “framework de referencia” apenas para a necessidades de vcs, e tbm se vc não usou a versão 1.0.0.0.0.0.1 do framework “Juquinha”

Agora vou testar o Atena e se servir pra os meus básicos propósitos vou usar, se não, paciência mas vou continuar procurando uma forma mais fácil e rápida de criar aplicações Java pois ficar indo no devaneio de alguns que procuram o supra sumo da master-ninja-plus tecnologia isso não dá, que não conseguem terminar nada pois sempre estão querendo usar a última da última versão de um framework novo, falam falam mas o que se ve é muita teoria e pouco resultado prático e eficiente.

E não ligue por esse estresse de alguns, quando sairem do mundinho deles de conceitos e mega-mega projetos e aprenderem que o dono da empresa quer saber é se funciona o sistema e pra quem desenvolve sistemas pra empresas(como uma softhouse e não como ?consultores?) quer ter um padrão de sistema, eles parem de fazer essa “tempestade em um copo d´água” Se são tão bons e conhecedores por que ficam trabalhando como terceiros e trocando de empresas porque a outra ofereceu 50 centavos a mais no valor-hora ???

Já foi… obrigado. :roll:

Não quero entrar na discussão.

Estou passando várias dificuldades com esses frameworks de “referência” que resolvem um problema específico e são utilizado para tudo.
Perdemos 2 meses treinando pessoas novas para utilizarem esses frameworks.

Quais as vantagens/desvantagens disto? Ainda não sei ao certo… só sei que o manual já está com 6 volumes…

http://www.joelonsoftware.com/articles/fog0000000024.html (Novamente o link…)

Abraços.

Bruno,

Concordo integralmente com você quando você diz que para se ter padronização não é necessária a criação de um framework. Mas não foi isso que fizemos!

Para que você entenda, tudo começou com a definição de uma arquitetura para um projeto específico. Essa definição levou em consideração um ou outro componente reutilizável que tínhamos desenvolvido, mas essencialmente, se limitava a frameworks open-source como Struts e Hibernate. Mas aí vieram o segundo e o terceiro projeto e acabamos por criar componentes para realizar tarefas que antes, ou eram difíceis de fazer, ou eram repetitivas, ou levavam muito tempo. Essas extensões a esses frameworks, que foram amadurecendo a cada projeto, é que resultou no Atena.

Então, não é que tenhamos escrito um framework para que fosse utilizado pelos projetos. O que aconteceu foi uma conseqüência natural de nosso processo de desenvolvimento.

Mais uma vez. Não existe imposição quanto ao uso do Atena, se ele não atender aos requisitos dos usuários. Mas veja, estamos falando de relações custo-benefício. Se hoje somos capazes de desenvolver sistemas a custo bem menores com o Atena, o que justificaria não utilizá-lo ? Como é que se defende uma idéia dessas para um gestor ? (veja o post do pbnf!)

Vamos lá!

Com relação à camada de controle:

• O Atena possibilita a configuração do struts.xml por meio de anotações (suportado parcialmente pelo Struts)
• O Atena adiciona o escopo de “action” aos já existentes (request, session, application)
• O Atena permite a injeção e conversão de dados da requisição em campos de tipos genéricos na action (não suportado pelo Struts)
• O Atena trata requisições síncronas e assíncronas exatamente da mesma forma
• O Atena tem um registro único, em java, de validações a serem aplicadas nos lados cliente e servidor
• O Atena tem anotações para injeção do usuário e do domínio (contexto da autenticação) corrente nas actions

Com relação à camada de visão:

• O Atena permite prototipação em java com reaproveitamento de código
• Todas as interfaces visuais do Atena são construídas em java
• Com isso, podem ser criados componentes de diversas granularidades
• Componentes podem herdar ou conter outros componentes (como pensar em herança com JSP ?)
• O Atena possui componentes do tipo “CasoDeUso” que encapsulam diversas páginas em um só componente
• Nenhum JSP é necessário
• O Atena permite a utilização de skins (substituição de templates do Velocity)

Com relação à camada de negócio:

• O Atena permite a execução de códigos compatíveis com a especificação EJB 3 dentro e fora de um container EJB
• O Atena possui tipos customizados (Data, Hora, Moeda…) que encapsulam conversões e formatações
• O Atena permite o armazenamento de comandos EJB QL em repositórios XML ao invés de em código
• O Atena permite sintaxes como “select pessoa from Pessoa pessoa [where pessoa.nome like :nome] order by pessoa.nome”

Isso pra citar alguns dos recursos.

[]s
Godoi

Agora sim, parece uma defesa justa ;). Dizer que vale a pena usar porque padroniza documentação não deveria convencer ninguém.

Aliás, não vou me meter a julgar o mérito do framework, não. Já foi possível perceber aqui nessa discussão, mesmo, que não traz muitos benefícios.

Só por curiosidade… Vocês escrevem a documentação, site, tutoriais, exemplos etc durante o trabalho, no MPF?

E nas horas vagas…

Mas não precisa, existe MUITO mais sendo jogado fora por aí…

E nas horas vagas…

Horas vagas? Vem cá, vocês não cumprem a portaria 707 não? :?

Jonatas, parabéns a você e todo o resto da equipe que desenvolveu o Atena.

Já dei uma olhada nas apresentações do projeto, além de alguns trechos de fontes, demos, etc… e por mim está legal, vai atender o objetivo de muita gente, e não só ao do MPF, e é isso que importa

[]s
Edson Luis Gonçalez

Tenho certeza que as críticas destrutivas de alguns acabaram servindo como uma verdadeira injeção de ânimo para os autores do Atenas. Vendo por esse outro ângulo podem até ser consideradas “positivas”. É aquela velha história: se te tacam limões, faça uma limonada.

O dia que eu fizer alguma coisa e ninguém falar que é uma merda, que não tem testes unitários, que já tem um igual, que é perda de tempo, então terei certeza de que o que eu fiz é um lixo e não vale ser continuado.

A Lógica Infalível de Saoj: parte 36823, ato 1728/B.

Obrigado pelas últimas considerações.

Aproveito para informar que estaremos disponibilizando esta semana a versão 4.0.4 do Atena, com inúmeras melhorias.