Validação por regressão

A seguir métricas base que foram inicialmente idealizadas para relativização das métricas por regressão polinomial:

1. Número de classes, realizando uma regressão em escopo de software.

2. Número de classes por pacote, resultando em uma regressão em escopo de “módulo”. 3. NOM, realizando uma regressão em escopo de classe.

4. AMLOC, realizando uma regressão em escopo de classe.

Não é possível idealizar esse resultado para métricas OO, mensuradas para cada classe, para entradas mais granularizadas como valores de métodos. A grande maioria das métricas tem seus valores para a classe como um todo, não podendo fazer distinção sobre a participação de cada método individualmente dentro daquele valor.

Nenhuma das formas propostas foi realmente implementada, apenas foi realizado uma discussão das possibilidades com as métricas que estavam disponíveis. Métricas de tamanho foram o alvo da regressão como variáveis independentes porque seriam uma forma de abstrair os resultados para projetos de diferentes escalas. Essencialmente os intervalos de valores anteriormente definidos seriam validados se a métrica estivesse de acordo com os mesmos para os parâmetros específicos do projeto sendo analisado, fazendo uma comparação entre o modelo de regressão e a análise manual subjetiva deste trabalho.

5.2.1.1 Regressão em escopo de software

A primeira observação que se faz sobre a realização de regressão em escopo de software utilizando os valores da evolução da API do sistema Android é capacidade de generalização de um modelo. De forma geral, o modelo seria criado com pontos com valores de número de classes variando de 5000 a 20000 classes. Como consequência, ar-gumentamos que o modelo de regressão não teria uma boa capacidade de generalização para projetos muito pequenos, como acontece com aplicativos, que possuem muitas vezes apenas algumas dezenas de classes, e são o alvo principal para utilização dessa regressão. Da mesma forma, a capacidade de predição para projetos que contenham bem mais que 20000 classes também seria prejudicada, uma vez que o modelo de regressão não veria nenhum nesse intervalo.

Figura 13 – Percentil 75 das métricas DIT, NOC, LCOM, ACC e ACCM

Para que isso pudesse ser realmente feito, os dados das métricas OO devem ser relacionados com as métricas de tamanho, demonstrando seu valor como dependente do valor dessas métricas. Se os dados obedecem um certo padrão, um funcional pode ser traçado para representar o comportamento dos mesmos.

Como podemos ver na Figura 13, onde é traçado o percentil 75 em função do número de classes, as métricas DIT, NOC, ACC, LCOM4 e ACCM podem ser representa-das por uma linha reta horizontal, enquanto RFC, plotada na Figura14, tem dados mais dispersos mas ainda podem ser representados por uma reta horizontal sem perda signifi-cativa nos percentis 75 e 90, que correspondem a grande maioria dos dados. Nas tabelas e gráficos apresentados nas seção anterior pode ser confirmado que dentro de cada percentil de cada métrica a variação é pequena. Não foram plotados os valores de outros percentis aqui por diferenciação de escala que exigiria uma quantidade absurda de gráficos, além de

Figura 14 – Percentil 75, 90 e 95 de RFC em função do número de classes

não terem tanta importância quanto os valores muito frequêntes apresentados no percentil 75.

Para algumas métricas essa regressão parece ser possível, isto é, um funcional real-mente pode ser traçado que representa a variação dos valores das métricas com o número de classes do projeto. Entretanto, para a ínfima variação nos percentis mais significativos para métricas importantes como ACC, LCOM4, DIT, NOC, RFC, ACCM, que são as principais métricas aqui analisadas, argumentamos que um valor referência se mostra tão útil quanto essa regressão, tornando-a desnecessária.

Além de poder utilizar um valor referência sem perda de valor semântico sobre o valor ideal da métrica, uma regressão em escopo de software da forma como foi proposta, pelo número de classes, não contém, com os dados aqui obtidos, um conjunto suficiente de dados para uma boa regressão. Em suma, temos poucas amostras para realizar esse estudo.

Como um pequeno problema adicional, os dados das métricas para os aplicativos se mostraram levemente diferentes para os dados da API do sistema, mesmo estando bem semelhantes, então argumentamos que utilizar apenas a API do sistema como insumo para o modelo de regressão resultaria em um modelo que não funciona tão bem para predizer valores de métricas de aplicativos. Para os aplicativos, que são projetos distintos, as métricas são extremamente dispersas em relação ao número de classes, tornando difícil representar bem os dados por um polinômio para realizar a regressão.

Para realização de um modelo de regressão polinomial a nível de software, não foi encontrada ao longo deste trabalho, dadas restrições de tempo e escopo, outra métrica que representasse bem o tamanho do projeto para relativização do resultado das métricas

OO.

5.2.1.2 Regressão em escopo de classe

Como uma segunda tentativa na direção de uma regressão polinomial, foi verificada a possibilidade de utilizar valores das métricas para cada classe, e não para o projeto. Tentamos então avaliar o valor ideal de uma métrica para uma classe, dado alguma variável independente que represente de alguma forma seu tamanho.

Figura 15 – ACCM em função de AMLOC na API versão 5.1.0

Figura 16 – ACC em função de AMLOC na API versão 5.1.0

Cada classe dentro de cada versão seria uma amostra para esse método, que teria então um total de mais de 100000 classes. Pensando dessa forma o problema de escala do escopo de software seria resolvido.

O problema nessa abordagem é que as métricas de tamanho que podem ser uti-lizadas também se mostraram independentes dos valores das métricas OO. Como pode

Figura 17 – ACC em função de AMLOC na API versão 5.1.0 com 95% dos dados

Figura 18 – DIT, NOC, LCOM, ACC e ACCM em função de AMLOC

ser visto nas Figuras 15 e 16, os valores de ACC e ACCM parecem oscilar bastante. É importante notar que a parte de maior valor do gráfico representa uma quantidade muito pequena de amostras como os próprios percentis já descrevem. A Figura 17 demonstra isso com o fato de que pouco menos de 5% dos dados de maior valor foram retirados (1000 amostras), deixando aproximadamente os dados até o percentil 95, e a escala do gráfico caiu drasticamente. De forma geral, esses pontos de maior valor tem representação estatística muito pequena. Como os percentis representam a grande maioria de valores, iremos utilizá-los para fazer essa comparação, em vez do valor de cada classe.

Como mostram as Figuras18e 19, a variação das métricas OO em seus percentis mais representativos em função de AMLOC ou NOM é mínima e os dados se apresentam na forma de uma linha horizontal. Apenas ACCM tem uma suave relação crescente com

Figura 19 – DIT, NOC, LCOM, ACC e ACCM em função de NOM

AMLOC como já discutido na seção anterior. Na verdade, apenas pelo fato de essas métricas não variarem muito ao longo das versões, já se pode prever esse resultado. 5.2.1.3 Regressão em escopo de pacote

Figura 20 – LCOM, ACC e ACCM em função do tamanho de módulo

Para fazer esse teste, foi separado cada pacote presente em cada versão do sistema, e utilizado como métrica de tamanho o número de classes nesse pacote. Os percentis para cada métrica eram calculados individualmente por pacote.

O problema encontrado nessa abordagem foi que as métricas eram dependentes do próprio pacote analisado e seu propósito, mas independentes de seu tamanho. Isso quer dizer que vários pacotes com mesmo número de classes apresentavam valores com nenhuma relação entre si. Basicamente, o mesmo problema de independência dos dados em relação a variável de tamanho foi encontrado aqui.

O gráfico da Figura 20 demonstra as métricas LCOM, ACC e ACCM para cada pacote em função dos seu número de classes. Podemos perceber que os valores tem uma grande variação que aparentemente independe do número de classes do pacote. Pacotes maiores podem parecer variar um pouco menos, mas isso se da pela quantidade menor de amostras em relação a pacotes pequenos.

Emfim, regressão neste contexto de métricas OO e métricas de tamanho não se mostrou um esforço válido para auxiliar desenvolvimento futuro de aplicativos. Mesmo no caso do escopo de software onde os dados podiam ser representados por um funcional, como a maioria dos valores se mostrou quase invariável ao longo das versões, ou com intervalos fixos, utilizar intervalos de referência tem tanta utilidade quanto uma regressão apresentaria.