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

Thread.start() Membro desde: 12/10/2007 13:05:11 Mensagens: 30 Offline

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:

http://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420
http://www.amazon.com/Pattern-Oriented-Software-Architecture-System-Patterns/dp/0471958697
http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215
http://www.amazon.com/Expert-One-One-Development-without/dp/0764558315
http://www.amazon.com/Better-Faster-Lighter-Java-Bruce/dp/0596006764

Thread.start() Membro desde: 12/10/2007 13:05:11 Mensagens: 30 Offline

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

jonatas@pgr.mpf.gov.br wrote:

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.

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?

jonatas@pgr.mpf.gov.br wrote:
2) Sobre a imposição de limitações do Struts 1 e do EJB 2

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

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

jonatas@pgr.mpf.gov.br wrote:
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.

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.

jonatas@pgr.mpf.gov.br wrote:
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 ?

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.

This message was edited 1 time. Last update was at 17/10/2007 07:29:45

(com alterações)

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

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.

pcalcado wrote:
- Então porque você tem que criar um mock para realizar um simples teste unitário fora de um container?

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

pcalcado wrote:
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.

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

pcalcado wrote:
... pode ser o ideal para algumas aplicações

Para as outras, utilizamos outras tecnologias!

jonatas@pgr.mpf.gov.br wrote:
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.

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

jonatas@pgr.mpf.gov.br wrote:
Isso não é necessário nem obrigatótio. Só que às vezes facilita os testes.

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

jonatas@pgr.mpf.gov.br wrote:

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

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?

jonatas@pgr.mpf.gov.br wrote: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!):

jonatas@pgr.mpf.gov.br wrote:
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.

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

jonatas@pgr.mpf.gov.br wrote:
Para as outras, utilizamos outras tecnologias!

Que bom.

Thread.start() Membro desde: 12/10/2007 13:05:11 Mensagens: 30 Offline

pcalcado wrote:(sobre testes) É preciso ou não?

Não. É opcional!

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

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

pcalcado wrote:Que bom.

Que bom que concordamos em algo!

[]s
Godoi

This message was edited 2 times. Last update was at 16/10/2007 21:29:03

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.

jonatas@pgr.mpf.gov.br wrote:
Isso não é necessário nem obrigatótio. Só que às vezes facilita os testes.

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

Thread.start() Membro desde: 12/10/2007 13:05:11 Mensagens: 30 Offline

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

Thread.start() Membro desde: 12/10/2007 13:05:11 Mensagens: 30 Offline

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,

Thread.start() Membro desde: 12/10/2007 13:05:11 Mensagens: 30 Offline

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

This message was edited 1 time. Last update was at 17/10/2007 08:50:22

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 ?

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