Garantia de seguir os padrões arquiteturais

Olá,

como vocês fazem para saber se o projeto está seguindo corretamente os padrões arquiteturais, e de codificação estabelecidos ?

Na verdade, algumas empresas criam funções como Inspetor de Códigos Fontes, que artesanalmente verificam se o código escrito está correto, seguindo os padrões e atestando a utilização de outros DPs.

No entanto essa tarefa é árdua, e pode ser falha, pois sabemos que o cérebro humano é passível de erros.

Eu estava pensando em utilizar AOP para isso, alguma outra sugestão ?

Bom, quanto a formatação, acho que o CheckStyle da conta disso. Tem como você configurar as regras do CheckStyle. Aí é só rodar um averiguação toda a noite...

Mas quanto a seguir padrões de arquitetura, aí tem que ser uma revisão mais manual mesmo...

Cara uma ferramenta bacana está sendo desenvolvidada aqui na UFCG, acho que se encaixa no que você perguntou.
Ela http://www.gmf.ufcg.edu.br/index.php/DesignWizard permite que sejam especificados testes numa semântica semelhante a usada no Junit para certificar que regras de design sejam atendidas, por exemplo o pessoal deste outro projeto http://www.ourgrid.org/ estava usando a ferramenta para impedir que threads de um módulo fizessem chamadas a objetos de outros módulos.

Velho, acho que sua ideia de aspectos é muito legal. Tava na aula da pos-graduação essa semana e o professor tava falando justamente dessa utilidade dos aspectos.

Alberto

thiago-manel wrote:Cara uma ferramenta bacana está sendo desenvolvidada aqui na UFCG, acho que se encaixa no que você perguntou.
Ela http://www.gmf.ufcg.edu.br/index.php/DesignWizard permite que sejam especificados testes numa semântica semelhante a usada no Junit para certificar que regras de design sejam atendidas, por exemplo o pessoal deste outro projeto http://www.ourgrid.org/ estava usando a ferramenta para impedir que threads de um módulo fizessem chamadas a objetos de outros módulos.

Beleza, olhei o DesignWizard e achei que ele é mais complicado de usar do que com AOP, fiz uns testes aqui rapidamente com AOP e é formidável, pois o aspectJ provê mecanismos de lançar ERROR ou WARNINGS quando você está compilando o projeto, fantástico!!!!

Realizei uma implementação de uma verificação de quebra com AOP rapidamente e me veio logo a idéia de quanto é poderoso a AOP.

A classe Aspect que vai definir as políticas de arquitetura da minha aplicação.

Aqui é o trecho de código onde ocorre a quebra de encapsulação, seria por exemplo uma Action com seus Events chamando a camada de Persitência.

O Eclipse quando vc tenta compilar já te mostra os erros!

View Full Size at Glowfoto

Cara, como a sintaxe do AspectJ com Annotations ficou horrível!

Ave maria!

Prefiro usar a linguagem mesmo, esse negócio de meter strings nas annotations é seboso... e nadas haver, não endendo porque utilizar annotations pra fazer isso. Mas deixando os comentários sobre o AspectJ de lado...

E se de repente eu faço uma subclasse de um DAO em um pacote que não existe e coloco ele na view, o que é que acontece? Uma bela e legítima violação invisível.

Isso é uma maneira terrível de se controlar esse tipo de coisa, os componentes deveriam ter acesso as suas dependências e nada mais, se você não quer que o DAO apareça na view, faça uma mágica aí e adicione um daqueles inúteis business delegates como dependência da view e pronto, o cara tem que usar o que tá lá dentro, até porque ele não vai saber qual DAO chamar, porque ele não conhece implementações, apenas interfaces.

Esse negócio de "seguir padrões arquiteturais" é muito mais cultural do que mecânico, se os programadores não estão fazendo isso naturalmente, ou tem alguma coisa errada com eles ou com o código.

Checkstyle + PMD + CruiseControl + MDICP*

* Monte de Index Card Pendurado

Maurício Linhares wrote:Cara, como a sintaxe do AspectJ com Annotations ficou horrível!

Ave maria!

Prefiro usar a linguagem mesmo, esse negócio de meter strings nas annotations é seboso... e nadas haver, não endendo porque utilizar annotations pra fazer isso. Mas deixando os comentários sobre o AspectJ de lado...

Eu já acho ao contrário, o uso de Annotations no AspectJ 5 permitiu com que não haja uma nova sintaxe para a construção de aspectos, seguindo as tendências dos principais frameworks da atualidade como Hibernate, EJB 3, VRaptor 2, etc...

Maurício Linhares wrote:
E se de repente eu faço uma subclasse de um DAO em um pacote que não existe e coloco ele na view, o que é que acontece? Uma bela e legítima violação invisível.

Essa poderia ser outra política para ser seguida em relação ao padrão arquitetural de pacotes, ou seja, todas as classes no pacote tal devem herdar da superclasse Y, etc.
Com AOP isso fica flexível ao ponto de que se você já tem componentes modulares sendo desenvolvidos com Aspect, mais facilmente você construirá essas politicas.

Maurício Linhares wrote:
Isso é uma maneira terrível de se controlar esse tipo de coisa, os componentes deveriam ter acesso as suas dependências e nada mais, se você não quer que o DAO apareça na view, faça uma mágica aí e adicione um daqueles inúteis business delegates como dependência da view e pronto, o cara tem que usar o que tá lá dentro, até porque ele não vai saber qual DAO chamar, porque ele não conhece implementações, apenas interfaces.

É , seria uma forma deselegante de tratar esse tipo de situação, a intenção é ajudar o desenvolvedor a construir suas classes e utilizar o padrão. Porque muita gente desenhar a arquitetura e dificilmente consegue depois que o projeto acaba ou no seu desenvolvimento se ele está fiel ao que foi desenhado.

Maurício Linhares wrote:
Esse negócio de "seguir padrões arquiteturais" é muito mais cultural do que mecânico, se os programadores não estão fazendo isso naturalmente, ou tem alguma coisa errada com eles ou com o código.

Infelizmente temos diversos perfis de programadores, e com isso não podemos realmente saber se ele está apto a entender rapidamente a arquitetura. Em metodologias XP realmente não sei se é muito interessante, aliás, é bom ter , mas sabemos que pelo nível dos programadores, poucas violações seráo cometidas.

O interessante que acho em utilizar AOP para isso é a capacidade de ajudar o desenvolvedor a construir por exemplo objetos somente por factories, ou definir se ele está definindo os nomes de métodos, classes corretamente, é show de bola! E acho que isso ainda prova que a AOP está aí para realmente ficar, é impressionante isso!

http://innig.net/macker/

cv wrote:Checkstyle + PMD + CruiseControl + MDICP*

* Monte de Index Card Pendurado

Idem ao CV, mas...
- CC
+ beetlejuice... bem mais bonitinho...
+ Clover em alguns casos pra ficar feliz tambem

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