SonarJ Community Edition oferece análise de arquitetura e gerenciamento para pequenas e médias aplicações Java. hello2morrow, a empresa por trás do software SonarJ, recentemente lançou a versão grátis da da ferramenta de análise de arquitetura. A edição comunitária pode ser usada para analisar aplicações Java com até 500 classes internas (aproximadamente 50 a 60 KLOC).
O gerenciamento da arquitetura pode ajudar com estruturas de estruturas de dependência limpas e livres de ciclos bem como melhoria da testabilidade e reusabilidade do código. Arquitetos de software podem usar SonarJ para definir a arquitetura e regras de qualidade, que então serão monitoradas na IDE (Eclipse) no workspace do desenvolvedor. Uma ferramenta como SonarJ ajuda aos arquitetos integrarem mais cedo o gerenciamento da arquitetura no processo de desenvolvimento.
A InfoQ falou com Alexander von Zitzewitz, CEO da hello2morrow, sobre a motivação por trás da release da community edition e o futuro road-map de projetos SonarJ.
Qual foi a motivação por trás do release do SonarJ Community Edition?
Nosso velho modelo de preço foi baseado no número de usuários usando SonarJ, mas independente do tamanho do projeto. Mas o benefício do SonarJ está intimamente relacionado com o tamanho do projeto. Embora SonarJ já era livre para open source e para uso não comercial, nós abordamos muitos desenvolvedores para oferecer um baixo custo pessoal de licença. Vimos também, que muitos projetos ainda usam muitas ferramentas básicas de dependência como JDepend ou Macker. Com SonarJ tivemos uma solução que foi tão superior, mas apenas dispónível para grandes projetos com uma ferramenta budget. Então nós pensamos em uma maneira de tornar nossa solução disponível para uma base maior de usuários sem comprometer seriamente nossa base de renda.
Nós decidimos adicionar o tamanho do projeto como um segundo parâmetro ao modelo de preço. Também decidimos tornar SonarJ grátis para projetos com até 500 classes. Este limite já suporta a maioria dos projetos e equivale a aproximadamente 50 a 60 KLOC. Nós queríamos ter a certeza que o Community Edition do SonarJ poderia ser usado em projetos sérios. Assim os usuários podem colher os benefícios e economizar tempo e dinheiro evitando todas as más consequências da erosão estruturais.
Para tornar a equação completa, os projetos com até 3000 classes pagam menos por uma licença comercial que antes, projetos maiores pagam mais. Nós achamos que esta abordagem é muito mais equilibrada e se encaixa bem com o valor fornecido pela integração do SonarJ dentro do processo de desenvolvimento.
Como o SonarJ compara com outras ferramentas como Structure 101?
A Structure101 é uma ferramenta poderosa com uma boa interface de usuário intuitiva. Como SonarJ ele suporta a definição de um modelo de arquitetura. Por outro lado eu penso que nosso modelo de meta arquitetura e a forma como nós visualizamos a arquitetura se encaixa melhor com projetos maiores. O SonarJ suporta o conceito de um projeto maior dividido em subprojetos e não somente suporte horizontal, mas também fatiamento vertical de projetos. Embora você possa alcançar uma coisa parecida no Structure101 através da criação de dois ou mais modelos de arquitetura separados, este requer mais esforço e não é muito intuitivo. Para grandes projetos o corte vertical (criação de slices verticais) é uma técnica muito importante para manter o tamanho dos artefatos arquitetônicos manejáveis.
Como a ferramenta SonarJ ajuda com o design e arquitetura de execução se comparada com outras técnicas tal como a utilização de Aspects, Code Inspections ou Model Driven Architecture (MDA)?
Primeiro de tudo usar SonarJ é completamente não intrusivo e pode ser usado em qualquer projeto Java, novo ou velho. Usar aspects é bastante intrusivo (você tem que integrar AspectJ dentro de seu processo build) e realmente não é apoiada por um modelo de meta arquitetura. Embora você possa definir restrições poderosas nunca há uma garantia. Cada arquiteto provavelmente usará um estilo diferente de restrições. Além do mais penso que a complexibilidade da definição de um conjunto de restrições sérias tendem a sair do controle rapidamente. O modelo de meta arquitetura por trás do SonarJ o torna fácil ter certeza, que você tem uma cobertura completa de todas as dependências em seu código. Nem o código nem o processo build precisa ser tocado para usar o SonarJ.
Code Inspections não são uma alternativa séria para checagem automática da arquitetura e regras de qualidade. Demora muito tempo e há um grande risco de esquecer sérios problemas estruturais.
MDA é outra estratégia para criar aplicações. Se a maior parte do código é gerado o benefício de analisar o código gerado para defeitos arquitetônicos é provavelmente muito pequeno. Um bom gerador de código esperançosamente torna claro, que a estrutura de código gerado é limpa. Portanto se você está usando MDA com sucesso e muito de seu código de base é gerado você provavelmente não precisará do SonarJ.
Qual é o road map futuro do projeto SonarJ?
Atualmente nós estamos trabalhando no release 4.1 que está previsto para Março de 2009. O foco deste release está na usabilidade e tunning de nosso modelo de meta arquitetura. Ainda este ano pensamos sobre como adicionar plugins para outras IDE's como IntelliJ ou NetBeans. Nós também podemos lançar uma versão C# do SonarJ chamada SonarShark.