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

Assuntos Gerais Notícias
#61

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:





#62

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.

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

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

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

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

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

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

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

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

#63

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.

#64

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

#65

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

É preciso ou não?

[quote=jonatas@pgr.mpf.gov.br]Mais uma vez você se refere a um processo que não conhece. O processo em questão é sim iterativo e incremental.
[/quote]

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

[quote=jonatas@pgr.mpf.gov.br]
Para as outras, utilizamos outras tecnologias![/quote]

Que bom.

#66

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

#67

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.

#68

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.

#69

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

#70

Teoricamente, pode ter sua utilidade.

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

[/quote]

#71

eu também.

#72

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,

#73

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

#74

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 ?

#75

Estamos considerando e provavelmente iremos usar.

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

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

#76

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

#77

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

#78

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.

#79

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

#80

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?