A avaliação da métrica COR foi realizada a partir da comparação de seus resul- tados com a avaliação qualitativa de um conjunto de classes. Os resultados também foram comparados aos valores da métrica LCOM [Chidamber & Kemerer, 1994]. Os resultados das medidas obtidas foram classificados da seguinte maneira: positivo, se o valor da medida está de acordo com a avaliação qualitativa; falso negativo, se a métrica aponta baixa coesão e a avaliação qualitativa aponta alta coesão; falso positivo, se a métrica aponta alta coesão e a avaliação qualitativa aponta baixa coesão.
As seis primeiras classes avaliadas são de aplicações desenvolvidas por alunos aprendizes de orientação por objetos. As três classes seguintes são da ferramenta de coleta de métricas denominada Connecta [Ferreira, 2006]. A avaliação qualitativa das classes é descrita a seguir:
1. Autor: uma classe que representa um Autor. Possui dados como código, nome e e-mail. A classe possui 7 métodos: um método get e set para cada atributo, e um método construtor que invoca os métodos set para os atributos da classe. Embora a classe represente uma única entidade do domínio do problema, ela enquadra-se como uma Data Class, pois possui somente métodos de acesso.
2. Artigo: uma classe que implementa um Artigo. Possui os dados código, título, palavras-chave, número de páginas, ano de publicação e lista de autores. A classe possui 14 métodos: um método get e set para cada atributo, um método construtor que invoca os métodos set para os atributos da classe e um método que permite incluir autor na lista de autores. Embora a classe represente uma única entidade do domínio do problema, ela enquadra-se como uma Data Class.
6.3. Avaliação da Métrica COR 101
3. GestaoArtigo: possui métodos para manipular lista de artigos (inclusão, pesquisa, alteração etc.) cadastrados no sistema. Possui também um método que, dados dois artigos, identifica seus autores em comum. A classe implementa duas funcionalidades: a primeira, legítima, que é a manipulação da lista de artigos do sistema; a segunda é a verificação de autores em comum entre dois artigos, que deveria ser implementada na classe Artigo. Essa classe possui, então, duas responsabilidades.
4. Cliente: possui sete atributos de cliente e seus respectivos métodos get e set. Não possui método construtor implementado. Embora a classe represente uma única entidade do domínio do problema, ela enquadra-se como uma Data Class.
5. Acomodacao: possui cinco atributos. O método construtor inicia apenas um dos atributos. Embora a classe represente uma única entidade do domínio do problema, ela enquadra-se como uma Data Class.
6. Hotel: classe principal da aplicação de reservas de acomodações em um hotel. Possui um método principal que chama outros da mesma classe, que executam funções tais como: incluir reserva, excluir reserva, incluir cliente, excluir cliente, incluir acomodação e excluir acomodação. A classe não implementa um tipo de dado, ela agrega um conjunto de tarefas procedimentais para a execução do software. Poderia ser melhorada se fosse dividida em quatro classes: a principal, que representa o hotel, uma de gestão de cliente, uma de gestão de acomodações e outra de gestão de reservas. A coesão da classe não pode ser considerada alta, pois não representa um único papel bem definido. Contudo, também não é baixa. Dentro da escala de coesão proposta por Myers [1975], avalia-se a coesão dessa classe como comunicacional, o segundo melhor nível de coesão. Em um módulo com este tipo de coesão, seus elementos pertencem ao domínio do problema a ser solucionado e comunicam-se entre si por meio de dados. Os elementos do módulo são dependentes de dados comuns quando referenciam um mesmo conjunto de dados ou quando trocam dados entre si. No caso dessa classe, as ações de incluir acomodação e incluir cliente devem ser executadas antes de incluir reserva, e as ações de exclusão são dependentes dos dados incluídos.
7. ClassModule: representa uma classe no software avaliado. É uma classe coesa, pois todos seus dados e métodos referem-se à representação deste tipo de dado.
8. ConnectionPath: representa um caminho entre duas classes. É uma classe coesa, pois todos seus dados e métodos referem-se à representação deste tipo de dado. Porém, há um método nesta classe, denominado printPath, que não executa ação alguma.
9. ClassCollector: esta classe implementa pelo menos três responsabilidades. A primeira responsabilidade, legítima, é a coleta de métricas de uma classe. A segunda responsabilidade é implementada pela disponibilização de dois méto- dos que permitem incrementar o número de conexões aferentes e eferentes da classe. Essas são duas métricas de classes que correspondem, respectivamente, ao número de outras classes do sistema que utilizam a classe avaliada e ao número de outras classes do sistema que são utilizadas pela classe avaliada. Esses são da- dos que deveriam fazer parte de outra classe do software, ClassModule, e não de ClassCollector. A classe possui um método, denominado openLogFile cujo objetivo é abrir um arquivo de log a ser utilizado pelos outros métodos. Entretanto, ele não chegou a ser utilizado em nenhum método da classe.
10. Env: é uma classe que implementa uma tabela de símbolos de um compilador [Aho et al., 2008]. A classe é coesa, uma vez que tem um propósito bem definido e todos os seus métodos destinam-se à implementação desse propósito.
Além dessas classes, foram avaliadas quatro outras classes: uma classe denom- inada PilhaFilaLista, que agrega a implementação dos tipos abstratos de dados pilha, lista e fila de inteiros; as classes Pilha, Lista e Fila que implementam os respectivos tipos de abstratos de dados. A classe PilhaFilaLista é obviamente pouco coesa, uma vez que implementa três responsabilidades. Os resultados da avaliação da métrica COR são relatados na Tabela 6.1.
Dos 14 casos analisados, os resultados de LCOM discordam da avaliação quali- tativa em 4 casos. Os resultados de COR estão de acordo com a avaliação qualitativa. Há também de se observar que o valor fornecido por LCOM não é um indicador fiel do grau de coesão interna da classe, mesmo quando identifica corretamente que a classe possui problemas de coesão. No caso da classe ClassCollector, por exemplo, con- siderada pouco coesa na análise qualitativa, que identificou três responsabilidades na
6.3. Avaliação da Métrica COR 103
Tabela 6.1. Avaliação da métrica COR
Classe Avaliação LCOM Comportamento
LCOM
COR Comportamento COR
Env Coesa 0 Positivo 1 Positivo
Autor Data Class 15 Positivo 0,33 Positivo
Artigo Data Class 73 Positivo 0,077 Positivo
GestaoArtigo 2 responsabilidades 0 Falso positivo 0,5 Positivo
Cliente Data Class 91 Positivo 0,125 Positivo
Acomodacao Data Class 46 Positivo 0,2 Positivo
Hotel Boa coesão, mas não máxima
259 Negativo 0,5 Positivo
ClassModule Coesa 17 Falso negativo 1 Positivo
ConnectionPath Coesa, mas poluída por um método que faz nada
0 Falso positivo 0,5 Positivo
ClassCollector 3 responsabilidades 1292 Positivo 0,333 Positivo PilhaFilaLista 3 responsabilidades 28 Positivo 0,333 Positivo
Pilha Coesa 0 Positivo 1 Positivo
Fila Coesa 0 Positivo 1 Positivo
Lista Coesa 0 Positivo 1 Positivo
classe, LCOM resultou em 1292 e COR em 0,33. Com o valor 1292 é extremamente difícil perceber o que exatamente está errado em relação à coesão interna da classe. O valor 0,33 indica que há três responsabilidades implementadas na classe, o que orienta melhor a identificar os problemas de coesão da classe. O mesmo ocorre nos casos da classe PilhaFilaLista.
No caso das classes Autor e Artigo, que são classes do tipo Data Class, o resultado de COR seria falso positivo se o cálculo da métrica considerasse métodos construtores.
A coesão da classe Hotel foi considerada boa, mas não máxima na análise qual- itativa. Na escala qualitativa, avaliou-se que a classe possui o segundo melhor nível de coesão, coesão comunicacional. O resultado de COR pode ser considerado posi- tivo, pois a métrica identificou a existência de uma responsabilidade, mas não possui recursos para qualificar o nível da coesão neste caso.
Embora a quantidade de casos analisados neste estudo não seja extensa, ela fornece um indício da eficácia de COR na avaliação de coesão interna de classes. COR foi utilizada no processo de reestruturação de um software com 68 classes, tendo auxili- ado satisfatoriamente a identificação de classes candidatas à reestruturação. A métrica COR foi coletada para todas as classes do sistema. Com base nos valores da métrica,
Figura 6.1. Frequência de valores de COR
foram identificadas as classes desse sistema que necessitaram ser subdivididas devido à deficiência de coesão interna.