ck
1.0.0
A CK calcula as métricas de código de nível de classe e método em projetos Java por meio de análise estática (ou seja, não é necessária um código compilado). Atualmente, ele contém um grande conjunto de métricas, incluindo o famoso CK:
CBO (acoplamento entre objetos) : conta o número de dependências que uma classe possui. As ferramentas verificam qualquer tipo usado em toda a classe (declaração de campo, tipos de retorno do método, declarações variáveis, etc.). Ignora as dependências para o próprio Java (por exemplo, java.lang.string).
CBO modificado (acoplamento entre objetos) : conta o número de dependências que uma classe possui. É muito semelhante ao CBO original do CKTOOL. No entanto, essa métrica considera uma dependência de uma classe como sendo as referências que o tipo faz com outras pessoas e as referências que recebe de outros tipos.
Fan-in : conta o número de dependências de entrada que uma classe possui, ou seja, o número de classes que fazem referência a uma classe específica. Por exemplo, dada a Classe X, o ventilador de X seria o número de classes que chamam X, referenciando-o como um atributo, acessando alguns de seus atributos, invocando alguns de seus métodos etc.
Fan-Out : conta o número de dependências de saída que uma classe possui, ou seja, o número de outras classes referenciadas por uma classe específica. Em outras palavras, dada a Classe X, o fan-out de X é o número de classes chamadas por X via referência de atributos, invocações de métodos, instâncias de objetos, etc.
DIT (árvore de herança de profundidade) : conta o número de "pais" que uma classe possui. Todas as classes têm DIT pelo menos 1 (todos herda Java.lang.Object). Para que isso aconteça, as classes devem existir no projeto (ou seja, se uma classe depende de X, que depende de um arquivo de jar/dependência e x depende de outras classes, o DIT é contado como 2).
NOC (número de crianças) : conta o número de subclasses imediatas que uma classe específica possui.
Número de campos : conta o número de campos. Números específicos para o número total de campos, estáticos, públicos, privados, protegidos, padrão, final e sincronizados.
Número de métodos : conta o número de métodos. Números específicos para o número total de métodos, métodos estáticos, públicos, abstratos, privados, protegidos, inadimplentes, finais e sincronizados. Os métodos construtores também contam aqui.
Número de métodos visíveis : conta o número de métodos visíveis. Um método é visível se não for privado.
Nosi (número de invocações estáticas) : conta o número de invocações para métodos estáticos. Ele só pode contar aqueles que podem ser resolvidos pelo JDT.
RFC (resposta para uma classe) : conta o número de invocações de método exclusivas em uma classe. Como as invocações são resolvidas via análise estática, essa implementação falha quando um método possui sobrecarga com o mesmo número de parâmetros, mas tipos diferentes.
WMC (classe do método de peso) ou complexidade de McCabe . Conta o número de instruções de ramificação em uma classe.
LOC (linhas de código) : conta as linhas de contagem, ignorando linhas e comentários vazios (ou seja, são linhas de código de código ou sloc). O número de linhas aqui pode ser um pouco diferente do arquivo original, pois usamos a representação interna do JDT do código -fonte para calculá -lo.
LCOM (falta de coesão dos métodos) : calcula a métrica LCOM. Esta é a primeira versão da Metric, que não é confiável. O LCOM-HS pode ser melhor (espero que você nos envie uma solicitação de tração).
LCOM* (Falta de coesão dos métodos) : Esta métrica é uma versão modificada da versão atual do LCOM implementada na ferramenta CK. O LCOM* é uma métrica normalizada que calcula a falta de coesão da classe dentro de um intervalo de 0 a 1. Então, quanto mais próximo de 1 o valor de LCOM* em uma classe, menor o grau de coesão dessa classe respectiva. Quanto mais próximo de 0 o valor de LCOM* em uma classe, maior a coesão dessa classe respectiva. Esta implementação segue a terceira versão do LCOM* definida em [1].
TCC (coesão da classe apertada) : mede a coesão de uma classe com um valor de valor de 0 a 1. O TCC mede a coesão de uma classe por meio de conexões diretas entre métodos visíveis, dois métodos ou suas árvores de invocação acessam a mesma variável de classe.
LCC (coesão de classe solta) : semelhante ao TCC, mas inclui ainda o número de conexões indiretas entre classes visíveis para o cálculo da coesão. Assim, a restrição LCC> = TCC é sempre mantida.
Quantidade de retorno : o número de instruções return .
Quantidade de loops : o número de loops (ou seja, para, enquanto, enquanto faz, aprimorado).
Quantidade de comparações : o número de comparações (ou seja, == e! =). Nota:! = Está disponível apenas em 0.4.2+.
Quantidade de tentativa/captura : o número de tentativas/capturas
Quantidade de expressões entre parênteses : o número de expressões dentro dos parênteses.
Literais de cordas : o número de literais de cordas (por exemplo, "John Doe" ). As cordas repetidas contam quantas vezes aparecem.
Quantidade de número : o número de números (ou seja, int, longa, dupla, flutuante) literais.
Quantidade de operações matemáticas : o número de operações matemáticas (vezes, divida, restante, mais, menos, merda esquerda, mudança direita).
Quantidade de variáveis : número de variáveis declaradas.
Blocos max aninhados : o maior número de blocos aninhados juntos.
Quantidade de aulas anônimas, classes internas e expressões de lambda : o nome diz tudo. Observe que sempre que uma classe anônima ou uma classe interna é declarada, ela se torna uma "nova classe inteira", por exemplo, CK gera AB e AB $ C, sendo C uma classe interna dentro de AB, no entanto, as expressões de lambda não são consideradas classes e, portanto, fazem parte da classe/método em que são incorporadas. Uma classe ou um método possui apenas o número de classes internas declaradas em seu nível, por exemplo, uma classe interna que é declarada dentro de um método m2, que está dentro de uma classe A anônima, que é declarada dentro de um método m, que finalmente é declarado em classes C, não é contado na classe C, mas apenas no método M2 (o primeiro método de nível é almofado) e não é a classe C.
Número de palavras exclusivas : Número de palavras exclusivas no código -fonte. No nível do método, ele usa apenas o corpo do método como entrada. No nível da aula, ele usa todo o corpo da classe como métricas. O algoritmo conta basicamente o número de palavras em um método/classe, depois de remover palavras -chave Java. Os nomes são divididos com base no estojo de camelo e no sublinhado (por exemplo, longname_likethis se torna quatro palavras). Consulte a classe WordCounter para obter detalhes sobre a implementação.
Número de declarações de log : número de instruções de log no código -fonte. A contagem usa o REGEX compatível com as chamadas SLF4J e LOG4J API. Consulte NumberOfLogStatements.java e os exemplos de teste ( NumberOfLogStatementsTest e fixtures/logs ) para obter mais informações.
Tem javadoc : booleano indicando se um método tem javadoc. (Apenas no nível do método por enquanto)
Modificadores : Modificadores Públicos/Abstractos/Privados/Protectados/Nativos de Classes/Métodos. Pode ser decodificado usando org.eclipse.jdt.core.dom.Modifier .
Uso de cada variável : com que frequência cada variável foi usada dentro de cada método.
Uso de cada campo : Com que frequência cada campo local foi usado dentro de cada método, o campo local são campos dentro de uma classe (as subclasses não estão incluídas). Também são detectados usos de campo locais indiretos, os usos de campo locais indiretos incluem todos os usos de campos na árvore de invocação local de uma classe, por exemplo, a invoca B e B usa o campo A, então a é indiretamente usado por A.
Invocações de métodos : Todos os métodos chamados diretamente, variações são invocações locais e invocações locais indiretas.
Nota: CK separa classes, classes internas e aulas anônimas. O LOC é a única métrica que não está completamente isolada dos outros, por exemplo, se A tiver uma declaração de uma classe interna B, então loc (a) = loc (classe A) + loc (classe interna B).
O CK é uma ferramenta de coleta de métricas de código Java, simplificada em uma estrutura simples que gira em torno de três pacotes primários:
Para a brevidade, dentro desta documentação, os prefixos de pacotes como com.github.mauricioaniche.ck são omitidos.
CK gerencia a orquestração de todo o processo de coleta de métricas. Ele inicializa os localizadores de métricas, lida com a partição de arquivos com base na memória disponível, configura os analisadores AST com configurações de ambiente apropriadas e gerencia o fluxo de execução em diferentes diretórios e dependências JAR. Ele ajusta dinamicamente seu comportamento com base em entradas do usuário como useJars , maxAtOnce e variablesAndFields para otimizar o processamento de arquivos Java para a coleção de métricas.ck . Esta classe processa argumentos de linha de comando para configurar e iniciar o processo de coleta de métricas. Ele lida com a entrada do usuário para o caminho do projeto, inclusão JAR, particionamento de arquivos, detalhes de métricas e configuração do diretório de saída. Runner orquestra a execução geral, inicializando e utilizando a classe CK e lidando com a saída do resultado através ResultWriter .FileASTRequestor , um componente do núcleo do Eclipse JDT (Java Development Tools). Ele desempenha um papel fundamental na estrutura da CK, orquestrando o processo de coleta de métricas. O MetricsExecutor coordena a criação da árvore de sintaxe abstrata (AST) para arquivos de origem Java, essencial para analisar e extrair métricas de código. METRICSFinder: Esta classe de utilidade, localizada em ck.utils , desempenha um papel crucial na identificação dinâmica e instanciação das classes de coletores métricos na estrutura CK. Ele tem como alvo as classes que implementam as interfaces ClassLevelMetric e MethodLevelMetric a partir do pacote de metrics .
O MetricsFinder utiliza a biblioteca Reflections para digitalizar e carregar classes de coletores métricas no tempo de execução, o que permite que o sistema CK seja extensível e adaptável a novas métricas sem exigir modificações para a arquitetura principal. Esse recurso é particularmente útil para integrar métricas personalizadas no processo de análise sem problemas.
CKVisitor: Um componente integral da estrutura CK, CKVisitor estende a classe ASTVisitor fornecida pela biblioteca Eclipse JDT (Java Development Tools), permitindo a análise detalhada e a coleção métrica diretamente da sintaxe abstrata (AST) do Java Code Code (AST).
O visitante foi projetado para atravessar vários nós do AST, como tipos e métodos, e aplicar ações específicas em cada nó. Ele gerencia efetivamente uma hierarquia de classes e métodos baseada em pilha, permitindo que as métricas sejam calculadas e coletadas no contexto do escopo do nó atual.
CKASTVISITOR: Implementado por classes métricas na ck.metrics , permitindo que cada métrica lida com nós de interesse específicos de AST, como invocações de métodos e criações de instância de classe.
ClassLevelMetric e MethodlevelMetric: Interfaces Definindo métodos para coletar métricas no nível da classe e no nível do método, respectivamente.
CKNotifier .CKClassResult e CKMethodResult com os dados coletados.O CK Framework incorpora vários padrões de design bem estabelecidos para melhorar a modularidade, a extensão e a manutenção de sua base de código. Esses padrões permitem que a estrutura lide com eficiência operações complexas, como atravessar árvores abstratas de sintaxe (AST), coletar métricas e notificar resultados. Abaixo estão os principais padrões de design utilizados:
Padrão do Visitante: As interfaces CKVisitor e CKASTVisitor implementam o padrão do visitante, que é fundamental ao manusear operações em vários nós AST sem alterar as classes dos elementos em que opera. Esse padrão é especialmente benéfico em cenários em que um componente precisa executar operações distintas e não relacionadas em uma hierarquia de classes de nós AST. Ele simplifica o código, externalizando a lógica operacional em objetos de visitantes, facilitando a adição fácil de novas operações sem modificar as classes de nó existentes. Essa separação de preocupações leva a uma base de código mais sustentável e extensível, onde as estruturas e operações do nó AST são dissociadas.
Notificador Padrão: A CK adota o padrão notificador através do uso do CKNotifier , que atua como um mecanismo central para transmitir os resultados da coleção de métricas para todos os observadores registrados. Esse padrão é crucial para a criação de uma arquitetura pouco acoplada, onde o sujeito (processo de computação métrica) é independente de seus observadores (processadores de resultados ou geradores de relatórios). Isso permite que a CK notifique vários componentes sobre a conclusão dos cálculos métricos sem acoplamento a componentes específicos, o que aumenta a flexibilidade e a escalabilidade do sistema.
Padrão de fábrica: A instanciação dos colecionadores métricos é gerenciada pelo MetricsFinder , que incorpora o padrão de fábrica. Esse padrão é utilizado para encapsular a lógica de instantar classes de coletores métricas específicas com base em decisões de tempo de execução. O padrão de fábrica simplifica o processo de adicionar novos tipos de colecionadores métricos sem perturbar o código existente, fornecendo uma arquitetura plug-and-play, onde novas métricas podem ser introduzidas perfeitamente. Também ajuda a manter a separação de preocupações, pois o processo de criação de objetos métricos é isolado da lógica principal da coleção métrica.
Ao alavancar esses padrões de design, a CK gerencia com eficiência a complexidade e garante que a estrutura permaneça robusta, adaptável e fácil de estender à medida que novos requisitos e tipos de métricas surgem.
Você precisa de pelo menos Java 8 para poder compilar e executar essa ferramenta.
Para usar a versão mais recente (que você deve), clone o projeto e gerar um frasco. Um mvn clean compile package gera o arquivo JAR único para você (consulte sua pasta de destino ).
Então, basta correr:
java -jar ck-x.x.x-SNAPSHOT-jar-with-dependencies.jar
<project dir>
<use jars:true|false>
<max files per partition:0=automatic selection>
<variables and fields metrics?:true|false>
<output dir>
[ignored directories...]
Project dir refere -se ao diretório onde o CK pode encontrar todo o código -fonte a ser analisado. O CK procurará recursivamente os arquivos .java. O CK pode usar as dependências do projeto para melhorar sua precisão. O use jars diz ao CK para procurar qualquer arquivo .jar no diretório e usá -los para melhor resolver os tipos. Max files per partition informam ao JDT o tamanho do lote para processar. Vamos decidir isso para você e começar com 0; Se ocorrerem problemas (ou seja, sem memória), você pensa em ajustá -lo. Variables and field metrics indicam ao CK se você deseja métricas nos níveis variáveis e de campo também. Eles são altamente refinados e produzem muita saída; Você deve ignorá -lo se precisar apenas de métricas no nível da aula ou do método. Finalmente, output dir consulte o diretório em que a CK exportará o arquivo CSV com métricas do projeto analisado. Opcionalmente, você pode especificar qualquer número de diretórios ignorados, separados por espaços (por exemplo, build/ ). Por padrão, .git e todas as outras pastas ocultas são ignoradas.
A ferramenta gerará três arquivos CSV: classe, método e níveis variáveis.
Aprenda pelo exemplo. Veja aula Runner.java .
Veja a versão mais recente da biblioteca no crachá no início deste Readme, ou em https://mvnrepository.com/artifact/com.github.mauricioaniche/ck.
Use o seguinte snippet em seu pom.xml. Atualize o XYZ com a versão mais recente da ferramenta (verifique mvnrepository.com ou o crachá no início deste arquivo ReadMe):
<!-- https://mvnrepository.com/artifact/com.github.mauricioaniche/ck -->
<dependency>
<groupId>com.github.mauricioaniche</groupId>
<artifactId>ck</artifactId>
<version>X.Y.Z</version>
</dependency>
Você também pode usar o plug -in CK Maven, desenvolvido por @jazzmuesli, que executa automaticamente o CK em seu projeto. Muito útil para os desenvolvedores: https://github.com/jazzmuesli/ck-mvn-plugin.
Esta ferramenta usa a Biblioteca Core JDT do Eclipse sob o capô para a AST Construction. Atualmente, a versão de conformidade está definida como Java 11.
Precisa de suporte para uma versão mais recente do idioma? O processo de adicioná -lo é muito direto, considerando contribuir com um PR:
pom.xml . Você pode usar um navegador de repositório como o repositório MVN para facilitar esse processo.pom.xml , atualize as propriedades source e target do plug -in MAVEN Compiler de acordo.CK.java : [...]
ASTParser parser = ASTParser.newParser(AST.JLS11);
[...]
JavaCore.setComplianceOptions(JavaCore.VERSION_11, options);
[...]
Porque a ferramenta nasceu apenas para calcular o CK ClasslevelMetrics, mas cresceu além das minhas expectativas ... A vida é engraçada!
Por favor, use a seguinte entrada do Bibtex:
@manual{aniche-ck,
title={Java code metrics calculator (CK)},
author={Maurício Aniche},
year={2015},
note={Available in https://github.com/mauricioaniche/ck/}
}
Basta enviar um PR! :)
Este software está licenciado sob a licença Apache 2.0.
