Abstract— This work presents an analysis of software complexity based on Shannon´s Communication Theory using Chidamber & Kemerer (C&K) Metrics. The complexity affects effort and cost of software development and maintenance. The main software artifact is its architecture which depends on good balance of structural decisions based on coupling and cohesion concepts. The entropy concept can help us to measure the disorder level of the system. This work proposes using entropy as reference to control software design based on C&K metrics. I also define thresholds for some metrics and calculate the entropy of jUnit software used as an example. The results are good that suggest next steps in software complexity.
Keywords— software architecture, complex systems, entropy theory, C&K metrics.
I. INTRODUÇÃO
S SISTEMAS de software atuais são, na sua maioria, desenvolvidos aplicando a abordagem orientada a objetos, com predomínio das linguagens Java e C++. A abordagem orientada a objetos torna o desenvolvimento de software mais próximo da realidade pois associa suas classes às entidades do mundo real, portanto mais próxima da realidade dos negócios e dos clientes.
Porém, uma boa solução de software depende de um bom levantamento de necessidades do cliente, especificação de requisitos e uma arquitetura de software. Esta abordagem usa seus métodos, técnicas e ferramentas para uniformizar o desenvolvimento, atender aos requisitos e possibilitar uma longa vida ao software. O artefato principal da solução de um software é o seu modelo de arquitetura representado pelo diagrama de classes.
Também é reconhecido que os sistemas estão cada vez maiores, aumentando a sua complexidade e dificultando a sua evolução. Atualmente, o software é considerado um sistema complexo. Segundo [1], sistema complexo é um sistema constituído de múltiplos componentes que se interagem, do qual o comportamento global não pode ser inferido simplesmente a partir do comportamento dos componentes, mas emerge a partir da interação dos seus componentes e da interação entre o sistema e seu ambiente.
Ao se tornarem complexos, é imprescindível que se possa avaliar a complexidade do software para diminuir custos de desenvolvimento e manutenção. Propostas de métricas de avaliação da qualidade de software apoiadas na arquitetura de software não são recentes, como pode ser visto em [2] e [3]. No início, estas se baseavam notadamente em contagens das estruturas de software tais como, a complexidade ciclomática de McCabe [4] e a de tamanho de software através de número
1 K. Hirama, Grupo de Sistemas Complexos, Departamento de Engenharia
de Computação e Sistemas Digitais, Escola Politécnica, Universidade de São Paulo, SP, Brazil, [email protected]
de linhas de código. Porém, atualmente, os sistemas são desenvolvidos na abordagem orientada a objetos que se apoiam em princípios tais como classes, encapsulamento, mensagens, polimorfismo, agregação, composição, generalização, especialização que não permitem o uso de métricas tradicionais da abordagem estruturada.
O objetivo deste trabalho é apresentar uma análise de complexidade de software baseado na teoria da comunicação (ou da entropia) de Shannon [5] para caracterizar a complexidade do software que impacta a sua evolução ao longo do ciclo de vida. Para tal, o trabalho está dividido nas seguintes seções: seção II discute os trabalhos relacionados; a seção III apresenta a teoria da comunicação de Shannon; a seção IV apresenta as métricas de Chidamber e Kemerer (C&K) e seu relacionamento com a complexidade; a seção V descreve e discute um estudo de caso; e a seção VI apresenta uma conclusão do trabalho.
II. TRABALHOS RELACIONADOS
[6] usou a função de entropia de Shannon [5] para avaliar a melhoria de qualidade estrutural do software cuja entropia em excesso (excess entropy) é afetada pelas reconfigurações da arquitetura do software.
[7] propôs uma métrica de entropia para manutenibilidade de software, conhecida como carga de entropia (entropy
loading). Ele considerou uma porção qualquer de sistema de
software implementado como um sistema de tratamento de mensagens. Assim, qualquer manutenção de software poderia ser considerada como uma modificação em um tratador de mensagens.
[8] descreveram os efeitos do reuso de software sobre métricas que são baseadas na função de entropia de Shannon [5]. Eles usaram também o conceito de carga de entropia (entropy loading) para determinar a informação compartilhada entre coleções de objetos ao invés da informação usada dentro de cada coleção.
[9] descreveram suas medições de complexidade baseadas na entropia de Shannon [5] e nas propriedades de medidas de complexidade propostas por [10]. Um experimento foi realizado para medir a complexidade de classes em C++, levando-se em conta a complexidade de uma classe e a complexidade inter-objetos. As propriedades foram parcialmente verificadas, mas o experimento mostrou-se efetivo pois identificou uma boa correlação entre métricas.
[11] descreveu a medição de complexidade usando os conceitos de acoplamento e coesão dos componentes de software e seus relacionamentos. Ele propôs medidas de acoplamento inter-módulos, intra-módulos e coesão baseadas na entropia de Shannon [5].
[12] descreveram, diferentemente de alguns trabalhos anteriores que foram baseados em código de software, um
K. Hirama1
Software Complexity Analysis Based on
Shannon´s Entropy Theory and C&K Metrics
estudo de complexidade do processo de desenvolvimento de software através da análise de logs de repositório de projetos de grande porte. A evolução do software que atendesse às mudanças do cliente deveria ser o mais suave possível. Para isto, os desenvolvedores necessitam reduzir e controlar a complexidade associada com sistemas de software durante o processo de desenvolvimento.
[13] propuseram medir a complexidade estrutural para diagramas de classes usando uma abordagem baseada na entropia de Shannon [5]. A medição usa um modelo de complexidade estrutural denominado grafo ponderado de dependências de classes (WCDG – Weighted Classe
Dependence Graph) para calcular uma nova medida de
complexidade estrutural denominado EDC, usando a distância entrópica entre duas variáveis aleatórias que representam as saídas e entradas das classes.
[14] propuseram a medida de degradação do software usando a entropia de Shannon [5] e métrica de complexidade ciclomática de McCabe [4] por esta ter alta correlação com a propensão a defeitos das classes da abordagem orientada a objetos. Os valores de entropia foram proporcionalmente maiores para de uma coleção de classes que requeriam mudanças do que aqueles que não sofreram mudanças entre as versões do software. Também foi verificado que a alta complexidade ciclomática dos componentes estava associada a mais atividades de manutenção do que aqueles com baixa complexidade ciclomática.
[15] propuseram um modelo de análise de estabilidade de uma estrutura de software baseado em conceitos de sistemas dinâmicos complexos, ou sejam, a entropia de Shannon [5] para medir a complexidade do software e a teoria do caos para medir a estabilidade do software. O modelo pode ser usado para definir uma estratégia de manutenções de software baseada na complexidade e estabilidade do diagrama de classes.
[16] discutiram o fenômeno da degradação que afeta os sistemas de software durante o seu ciclo de vida. Argumentaram que muitas métricas de complexidade são difíceis de interpretar e o seu uso para monitorar atividades de manutenção são dispendiosas. Eles propuseram medir a entropia dos sistemas de software para avaliar a sua degradação usando medidas diretas de software que contribuem para a sua qualidade tais como, número de defeitos descobertos, número de defeitos não detectados (descobertos durante o uso do software) e esforço de manutenção.
[17] propuseram uma avaliação de complexidade (ou grau de desordem) de design de software com a métrica WMC (Weighted Methods per Class) de [18] e [19] expressada em termos de entropia de Shannon [5]. Experimentos com seis projetos em Java mostraram que um grupo de classes com valores de entropia maiores é mais propenso à degradação, pois é extremamente difícil avaliar a independência de um módulo em um sistema de software. O estudo não considerou outras métricas de C&K.
[20] e [21] realizaram uma avaliação de manutenibilidade de software baseada em métricas de C&K. Para isto, analisaram 21 versões do software jUnit e verificaram que é
possível prever uma tendência de manutenibidade de código de software analisando a evolução da métricas de C&K.
III. TEORIA DA COMUNICAÇÃO
Uma das teorias mais discutidas e aplicadas para o estudo de sistemas complexos é a Teoria da Comunicação desenvolvida por [5]. Baseada nos pesquisas da Termodinâmica, ele definiu a entropia como o grau de incerteza de ocorrência de informação nas mensagens geradas por sistemas de comunicação. Quanto mais incerto, maior é a entropia ou maior é a quantidade de informação contida na mensagem.
Outra forma de interpretar a entropia é o grau de desordem contida em um sistema. Em sistemas de software, a entropia pode ser usada como grau de complexidade de sua estrutura. Quanto maior a entropia, mais complexa e dispendiosa é o seu desenvolvimento e evolução.
A função de entropia H (medida em bits) é a média de informação recebida em uma mensagem e é definida como:
H (P) = H (p1, p2, ..., pn) = − ∑ (pk log2 pk), k = 1...n sendo: P – variável aleatória discreta,
probabilidade pk > 0, qualquer k ϵ {1, 2, ..., n) e ∑ pk = 1
A entropia atinge seu máximo (1) quando todas as saídas tem a mesma probabilidade de ocorrência. A entropia é zero (0) quando uma das saídas tem probabilidade 100%.
IV. MÉTRICAS DE C&K
Um dos conjuntos de métricas de software mais discutidas é o de C&K [18] e [19]. Eles propuseram um conjunto de métricas para projetos orientados a objetos que permitiria medir a melhoria do processo de desenvolvimento de software, mais específicamente, para o projeto orientado a objetos (OOD – Object-Oriented Design). OOD tem por objetivo projetar as classes/objetos e os seus relacionamentos. Trabalhos, como os de [22], [23], [24], [25] e [26], discutiram as métricas de C&K que continuam atuais por ainda não haver um consenso sobre o seu uso efetivo para avaliar o projeto de software.
As métricas propostas por [19] são:
- WMC (Weighted Methods per Class): É definida como o somatório das complexidades dos métodos de uma classe. Se todas as complexidades dos métodos forem consideradas unitárias, então o WMC é igual a n, o número de métodos da classe.
- DIT (Depth of Inheritance Tree): É definida como o comprimento máximo de um nó para a raiz da árvore de heranças.
- NOC (Number Of Children): É definida como o número de subclasses imediatamente subordinadas de uma classe dentro da hierarquia de classes.
- CBO (Coupling Between Object classes): É definida como o número de outras classes às quais a classe está acoplada.
- RFC (Response For a Class): É definida como o número de métodos da classe que podem ser invocados em resposta a uma mensagem de um objeto ou por algum método da classe. - LCOM (Lack of COhesion in Methods): É definida como o número de pares de métodos da classe que apresentam similaridades de variáveis usadas pelos métodos.
[26] e [27] classificaram as métricas de C&K segundo os seguintes atributos de qualidade de software [28]:
- Compreensibilidade: Quão fácil é compreender o projeto do software?
- Manutenibilidade: Quão fácil é a mudança da estrutura ou do componente do software?
- Testabilidade: Quão fácil é estabelecer e verificar os critérios de testes do software?
- Reusabilidade: Quão fácil é realizar o reuso de parte ou componente do software?
- Eficiência: Quão eficientemente os elementos básicos do software são usados?
- Esforço de Desenvolvimento: Quanto esforço é requerido para o desenvolvimento do software?
Segundo [28], o atributo de complexidade é o grau em que um sistema ou componente tem em um projeto ou implementação que é difícil de entender (dificuldade de compreensão) e verificar (dificuldade de testes). A Tabela I apresenta a relação entre atributos de qualidade de software e as métricas de C&K, de acordo com [19], [26] e [27].
Observando a Tabela I, os atributos relacionados com a complexidade (compreensibilidade e testabilidade) são WMC, RFC, CBO, DIT e NOC. Somente LCOM não foi incluído, segundo a análise dos autores pesquisados. LCOM (falta de coesão) indica que as classes precisam ser subdivididas para torna-las mais reusáveis, indica menor eficiência de uso das classes e também aumenta o esforço de desenvolvimento.
TABELAI
RELAÇÃO ENTRE ATRIBUTOS DE QUALIDADE E MÉTRICAS DE C&K
Atributos de
Qualidade Métricas de C&K
WMC RFC LCOM CBO DIT NOC Compreensibilidad e ② ②③ ②③ Testabilidade ①②③ ①③ ② ①②③ Manutenibilidade ①②③ ② ①②③ Reusabilidade ①②③ ② ①②③ ①②③ ①②③ Eficiência ② ② ② ② Esforço(*) ①③ ③ (*) Esforço de desenvolvimento ① Chidamber e Kemerer[19] ② Rosenberg e Hyatt [27] ③ Kulkarni, Kalshetty e Arde [26]
A Fig. 1 apresenta o relacionamento entre os atributos de qualidade.
Figura 1. Relacionamento entre os atributos de qualidade.
A complexidade é inversamente relacionada com a compreensibilidade. A compreensibilidade é diretamente relacionada com a manutenibilidade e reusabilidade e, inversamente com o esforço.
A complexidade é inversamente relacionada com a testabilidade. A testabilidade é diretamente relacionada com a manutenibilidade, reusabilidade e a eficiência.
Por outro lado, as métricas WMC, RFC, CBO, DIT e NOC estão diretamente relacionadas com a complexidade e inversamente com compreensibilidade e testabilidade.
Para a análise de valores de métricas de C&K, é necessário definir os limites (thresholds) de projeto. Segundo [29], estes limites são muito sensíveis ao tempo de experiência específica de negócio e das equipes de projeto. Eles são influenciados por diversos fatores tais como, tecnologia aplicada e conhecimento das equipes de projeto. Os limites podem ser definidos em termos de valores desejáveis e indesejáveis, com alguma margem de erro. Estes podem ser usados para corrigir eventuais defeitos ou estabelecer níveis aceitáveis de qualidade de um projeto de software.
Por não existirem limites pré-definidos para as métricas de C&K, alguns autores estabeleceram estes limites empiricamente baseado em análises exploratórias de projetos de software, conforme pode ser visto na Tabela II.
TABELAII
VALORES DESEJÁVEIS DE MÉTRICAS DE C&K
Estes são considerados valores desejáveis nos projetos analisados. Os projetos que estejam fora desses limites devem ser inspecionados para eventual reestruturação de suas classes. [20] e [21] fizeram um estudo sobre o tipo ou grau de correlação entre as métricas de C&K tomando por base o software jUnit. Foi verificada uma forte correlação entre as
Autor(es) Métricas de C&K
WMC RFC CBO DIT NOC LCOM Lorenz e Kidd [29] <= 20 <= 6 Rosenberg, Stapko e Gallo [30] <= 25 <= 50 <= 5 < 2 Kulkarni, Kalshetty e Arde [26] <= 10 <= 20 <= 5 1 e 2 1 <= 20 Misra [31] <= 100 <= 100 <= 5
métricas. Ao todo foram estudadas 21 versões do jUnit, sendo a primeira versão 2.0 com 31 classes e a última versão 4.9b2 com aproximadamente 560 classes. Houve uma reestruturação do jUnit entre as versões 3.8 e 4.0, onde o numero de classes passou de 79 para 240 classes. As correlações foram grandes entre os pares WMC-CBO, WMC-LCOM, CBO-RFC e RFC-LCOM. A correlação foi quase perfeita para WMC-RFC.
V. ESTUDO DE CASO E DISCUSSÃO
O objetivo do estudo de caso é analizar a complexidade estrutural de um software baseado na variação de sua entropia a medida que o software evolui nas suas diversas versões. Quanto maior a entropia maior é a complexidade do software. O software escolhido é o jUnit e as métricas de C&K escolhidas para o estudo são a WMC e RFC. A questão a ser estudada é se as entropias obtidas a partir destas métricas podem ser usadas para analisar a evolução da complexidade de um software. Os dados usados para o cálculo da entropia foram adaptados de [20], obedecendo os valores limites desejáveis das métricas de C&K definidos por [26] por serem mais restritivos. Assim, as faixas adotadas para a métrica WMC e RFC são:
0 <= WMC 1 < 10 (desejável) – 80% (mínimo) das classes 10 < = WMC 2 < 30 (aceitável)
30 <= WMC 3 < 100 (indesejável) WMC >=100 (proibitivo) – 0%
0 <= RFC 1 < 20 (desejável) – 80% (mínimo) das classes 20 <= RFC 2 < 40 (aceitável)
40 <= RFC 3 < 100 (indesejável) RFC >= 100 (proibitivo) – 0%
As classes com WMC ou RFC maior que 100 devem ser reestruturadas. Se forem observadas as faixas e o percentual mínimo de desejável, a entropia máxima baseada em WMC ou RFC será 0,9219 bits. Projetos com entropia menores apresentarão baixos níveis de complexidade, com boa compreensibilidade e testabilidade.
A Fig. 2 apresenta a evolução do número de classes do jUnit nas suas 21 versões.
As Tabelas III e IV apresentam os dados das 21 versões do software jUnit para as métricas WMC e RFC, respectivamente.
A Fig. 3 apresenta as variações de entropia baseadas nas métricas WMC e RFC.
Figura 2. Evolução do número de classes versus as versões do jUnit. TABELAIII
DADOS DE PERCENTUAIS DE WMC DO SOFTWARE JUNIT (ADAPTADA DE [20])
Versão # Classes WMC 1 WMC 2 WMC 3 Entropia (WMC)
2.0 31 87,10% 12,91% 0,00% 0,5548 2.1 36 88,89% 11,12% 0,00% 0,5034 3.0 57 91,23% 8,77% 0,00% 0,4287 3.2 57 91,23% 8,77% 0,00% 0,4287 3.4 50 86,00% 14,00% 0,00% 0,5842 3.5 59 88,14% 11,86% 0,00% 0,5253 3.6 59 88,14% 11,86% 0,00% 0,5253 3.7 59 88,14% 11,86% 0,00% 0,5253 3.8 79 92,41% 7,60% 0,00% 0,3878 3.8.1 81 90,12% 9,87% 0,00% 0,4650 3.8.2 87 89,66% 10,35% 0,00% 0,4799 4.0 240 93,33% 6,67% 0,00% 0,3535 4.1 246 93,50% 6,51% 0,00% 0,3472 4.2 257 93,77% 6,23% 0,00% 0,3365 4.3.1 267 94,01% 5,99% 0,00% 0,3270 4.4 309 93,53% 6,47% 0,00% 0,3458 4.5 405 94,81% 5,19% 0,00% 0,2944 4.6 431 94,90% 5,10% 0,00% 0,2906 4.7 482 95,02% 4,98% 0,00% 0,2855 4.8 508 95,08% 4,93% 0,00% 0,2833 4.9b2 563 95,38% 4,62% 0,00% 0,2700
A Fig. 3 apresenta uma correlação muito boa entre as métricas WMC e RFC, conforme obtido por [20]. Tomando-se por base a máxima entropia de 0,9219 bits do software, pode-se verificar que os valores de entropia (WMC e RFC) são muito baixos, indicando baixa complexidade do software jUnit, apesar do crescimento significativo do número de classes entre as versões, a partir da versão 4.0.
Pode-se também fazer uso da entropia como indicador de boas arquiteturas de software. O desenvolvedor poderá usar o valor máximo de entropia como referência e atuar no projeto das classes de maneira a atender às faixas desejáveis e os percentuais mínimos de classes para WMC e RFC.
TABELA IV
DADOS DE PERCENTUAIS DE RFC DO SOFTWARE JUNIT (ADAPTADA DE [20])
Figura 3. Variações de entropia nas 21 versões do jUnit baseadas nas métricas WMC e RFC, em relação à entropia máxima.
Pode-se controlar a complexidade de um software e tomar ações corretivas do projeto à medida que os valores de entropia se aproximem do máximo definido ou seja, indicando níveis maiores de degradação do software. Por exemplo, a entropia (RFC) da versão 2.0 é 0,965491 bits, enquanto a entropia (WMC) da mesma versão é 0,5548 bits. A versão 2.1 já apresentou uma queda nas duas entropias. Os valores de entropia seguiram em queda até 50% para RFC e até 70% para WMC até a última versão analisada, indicando uma redução significativa da complexidade do software apesar do aumento do número de classes.
VI. CONCLUSÃO
A redução de esforço e custo de desenvolvimento e manutenção de software é um dos maiores objetivos de negócio nos dias de hoje. As abordagens de projeto que apoiam a monitoração da complexidade do software estão sendo discutidas para atingir este objetivo. A teoria de entropia de Shannon associada às métricas de C&K é uma abordagem bastante promissora.
Outros trabalhos estão sendo desenvolvidos evoluindo para outras métricas de C&K e buscando novas correlações que aprimorem os resultados aqui discutidos.
REFERÊNCIAS
[1] XIONG, J. New Software Engineering Paradigm Based on Complexity Science – An Introduction to NSE. Springer, 2011. 783p.
[2] DARCY, D. P.; KEMERER, C. F.; SLAUGHTER, S. A.; TOMAYKO, J. E. The Structural Complexity of Software: An Experimental Test. IEEE Transactions on Software Engineering. v. 31, n. 11. November, 2005. pp. 982-995.
[3] DARCY, D. P.; DANIEL, S. L.; STEWART, K. J. Exploring Complexity in Open Source Software: Evolutionary Patterns, Antecedents, and Outcomes. In: Proceedings of the 43th Hawaii International Conference on System Sciences. 2010. pp. 1-11.
[4] McCABE, T. J. A Complexity Measure. IEEE Transactions on Software Engineering, v. SE-2, n. 4. IEEE. December, 1976. pp. 308-320. [5] SHANNON, C. E. A Mathematical Theory of Communication. Bell
Syst. Tech. J.27, 1948. pp. 379-423.
[6] MOHANTY. S. N. Entropy Metrics for Software Design Evaluation. The Journal of Systems and Software. v. 2, I. 1, February. 1981. pp. 39-46.
[7] CHAPIN. N. An Entropy Metric for Software Maintainability. Vol.II: Software Track, In: Proceedings of the Twenty-Second Annual Hawaii International Conference. v. II. 1981. pp. 522-523.
[8] TORRES, W. R.; SAMADZADEH, M. H. Software Reuse and Information Theory based Metrics. In: Proceedings of the Symposium on Applied Computing. April. 1991. pp. 437-446.
[9] KIM, K.; SHIN, Y.; WU, C. Complexity Measures for Object-Oriented Program Based on the Entropy. In: Proceedings of the Second Asia Pacific Software Engineering Conference – APSEC. 1995. pp. 127-136. [10] WEYUKER, E. J. Evaluating Software Complexity Measures. IEEE
Transactions on Software Engineering, v. 14, n. 9. IEEE. September, 1988. pp. 1357-1365.
[11] ALLEN, E. B. Measuring Coupling and Cohesion: An Information-Theory Approach.. In: Proceedings on Seventh International Software Metrics Symposium. April. 2001. pp. 124-134.
[12] HASSAN, A. E.; HOLT, R. C. The Chaos of Software Development. In: Proceedings of International Workshop on Principles of Software Evolution – IWPSE. Helsinki, Finland. September. 2003.
[13] ZHOU, Y.; XU, B. Measuring Structural Complexity for Class Diagrams: An Information Theory Approach. In: ACM Symposium on Applied Computing. Santa Fe, USA. March. 2005. pp. 1679-1683. [14] OLAGUE, H. M.; ETZKORN, L. H.; COX, G. An Entropy-Based
Approach to Assessing Object-Oriented Maintainability and Degradation – A Method and Case Study. In: Proceedings of the International Conference on Software Engineering Research and Practice & Conference on Programming Languages and Compilers, SERP. v. 1, Las Vegas, USA. June. 2006. pp. 442-452.
[15] SANTOS Jr., J. C.; HIRAMA, K. A Model Based on Complex Dynamical Systems Concepts for Class Diagrams Relationship`s Structure Stability Analysis. In: 5º. Congresso Internacional de Gestão de Tecnologia e Sistemas de Informação – CONTECSI. Junho. 2008. [16] BIANCHI, A.; CAIVANO, D.; LANUBILE, F.; VISAGGIO, G.
Evaluating Software Degradation through Entropy: Technical Report. In: Proceedings of Seventh International Software Metrics Symposium. April. 2000. pp. 86-96.
[17] SELVARANI, R.; NAIR, T. R. G.; RAMACHANDRAN, M.; PRASAD K. Software Metrics Evaluation Based on Entropy. Journal of Computer Science. v. 8, n. 2. June. 2009. pp. 20-28. Versão #Classes RFC 1 RFC 2 RFC 3 Entropia (RFC) 2.0 31 77,42% 16,13% 6,45% 0,965491 2.1 36 80,56% 11,11% 8,33% 0,902108 3.0 57 84,21% 10,53% 5,26% 0,774227 3.2 57 84,21% 10,53% 5,26% 0,774227 3.4 50 82,00% 14,00% 4,00% 0,817634 3.5 59 84,75% 11,86% 3,39% 0,732623 3.6 59 84,75% 11,86% 3,39% 0,732623 3.7 59 84,75% 11,86% 3,39% 0,732623 3.8 79 87,34% 7,59% 5,06% 0,670711 3.8.1 81 86,42% 9,88% 3,70% 0,68788 3.8.2 87 85,06% 11,49% 3,45% 0,724812 4.0 240 88,33% 8,75% 2,92% 0,614516 4.1 246 88,21% 8,94% 2,85% 0,617367 4.2 257 88,72% 8,17% 3,11% 0,604132 4.3.1 267 89,89% 7,12% 2,99% 0,561039 4.4 309 89,97% 6,80% 3,23% 0,560876 4.5 405 90,62% 6,67% 2,72% 0,530758 4.6 431 90,72% 6,50% 2,78% 0,527482 4.7 482 91,29% 6,22% 2,49% 0,501912 4.8 508 91,54% 6,10% 2,37% 0,490831 4.9b2 563 92,18% 5,68% 2,14% 0,462014
[18] CHIDAMBER, S. R.; KEMERER, C. F. Towards a Metrics Suite for Object Oriented Design. In: Conference Proceedings on Object-oriented Programming Systems, Languages, and Applications – OOPSLA. 1991. pp. 197-211.
[19] CHIDAMBER, S. R.; KEMERER, C. F. A Metrics Suite for Object Oriented Design. IEEE Transactions on Software Engineering. v. 20, n. 6. June. 1994. pp. 476-493.
[20] BARBOSA Jr., N. Avaliação da Manutenibilidade de Software Através das Métricas de C&K. Dissertação de Mestrado. Instituto de Pesquisas Tecnológicas. 2011. 108p.
[21] BARBOSA Jr., N.; Hirama, K. Assessment of Software Maintainability Evolution Using C&K Metrics. IEEE Latin America Transactions. v. 11. n. 5. September. 2013. pp. 1232-1237.
[22] CHIDAMBER, S. R.; DARCY, D. P.; KEMERER, C. F. Managerial Use of Metrics for Object-Oriented Software: An Exploratory Analysis. IEEE Transactions on Software Engineering. v. 24. n. 8. August. 1998. pp. 629-639.
[23] BASILI, V. R.; BRIAND, L. C.; MELO, W. L. A Validation of Object-Oriented Design Metrics as Quality Indicators. IEEE Transactions on Software Engineering, v. 22, n. 10. 1996. pp. 751-761.
[24] EMAM, K. E.; BENLARBI, S.; GOEL, N.; RAI, S. N. The Confounding Effect of Class Size on the Validity of Object-Oriented Metrics. IEEE Transactions on Software Engineering. v. 27, n. 7. July. 2001. pp. 630-650.
[25] SUBRAMANYAM, R.; KRISHNAN, M. S. Empirical Analysis of CK Metrics for Object-Oriented Design Complexity: Implications for Software Defects. IEEE Transactions on Software Engineering. v. 29, n. 4. April. 2003. pp. 297-310.
[26] KULKARNI, U. L.; KALSHETTY, Y. R.; ARDE. V. G. Validation of CK Metrics for Object Oriented Design Measurement. In: Third International Conference on Emerging Trends in Engineering and Technology. 2010. pp. 646-651.
[27] ROSENBERG, L. H.; HYATT, L. E. Software Quality Metrics for Object-Oriented Environments. Crosstalk Journal. April. 1997. [28] IEEE. Standard Glossary of Software Engineering Terminology. IEEE
Std 610.12. 1990.
[29] LORENZ, M.. KIDD, J. Object-Oriented Software Metrics. Prentice Hall, 1994. 146p.
[30] ROSENBERG, L. H.; STAPKO, R.; GALLO, A. Risk-based Object Oriented Testing. In: Twenty-Fourth Annual Software Engineering Workshop. December. 1999.
[31] MISRA, S. Evaluation Criteria for Object-oriented Metrics. Acta Polytechnica Hungarica. v. 8, n. 5. 2011. pp. 109-136.
Kechi Hirama received his B.S., M.S., Ph.D. and Associate Professor degrees in Computer Engineering from Escola Politécnica of the University of São Paulo, São Paulo, Brazil in 1980, 1988, 1996 and 2008, respectively. He worked 15 years in the Control Systems and Industry Automation areas in research organizations and since 1996 he has been Professor of the Department of Computer and Digital Systems Engineering of Escola Politécnica of the University of São Paulo. His interests include complex systems and system and software engineering.
