Detectando Problemas de Design em Diagramas de Classes:
Um Estudo Experimental
Isela Macía1, Cláudio Sant’Anna2, Arndt von Staa1 1
Departamento de Informática – PUC-Rio – Rio de Janeiro – RJ – Brazil
{ibertran, arndt}@inf.puc-rio.br
2
Departamento de Ciência da Computação – UFBA – Salvador – BA – Brazil
santanna@dcc.ufba.br
Abstract. Metric-based mechanisms have been defined for detecting software
design flaws. Most of these mechanisms focus on analyzing the source code. However, to reduce unnecessary rework it is important to detect design flaws at least since software models. This work proposes two strategies for detecting two specific design anomalies – “god class” and “data class” – in class diagrams. We carried out an experiment to obtain evidence on the accuracy of the proposed detection strategies. The study showed that the application of the strategies on class diagrams identifies, with high accuracy, which classes are also suspect of having the design flaws on the source code.
Resumo. Mecanismos baseados em métricas têm sido definidos para a
detecção de problemas de design de software. A maioria desses mecanismos foca na análise do código fonte. É importante, porém, para reduzir retrabalho inútil, detectar problemas de design pelo menos desde os modelos dos sistemas. Este trabalho propõe estratégias para detectar dois problemas de design específicos – “god class” e “data class” – em diagramas de classes. Foi realizado um estudo experimental a fim de obter evidência da acurácia das estratégias de detecção propostas. O estudo mostrou que a aplicação das estratégias em diagramas de classes identifica, com elevada acurácia, quais classes também são suspeitas de ter os problemas de design no código fonte.
1. Introdução
Apesar de ser um mecanismo poderoso para avaliar e controlar a qualidade do design de software, métricas de software apresentam uma limitação intrínseca: não é trivial obter interpretações adequadas a partir de medições de design [Marinescu, 2004]. O valor de uma métrica pode indicar uma anomalia no código, mas deixa o desenvolvedor quase sempre sem indicação da causa da anomalia [Marinescu, 2004; Lanza & Marinescu, 2006]. Para tratar dessa limitação das métricas, alguns pesquisadores propuseram mecanismos para formular regras baseadas em métricas de código fonte que capturam desvios dos princípios e heurísticas de bom design orientado a objetos [Sahraoui et al, 2001; Martin, 2002, Emden & Moonen, 2002; Marinescu, 2004; Munro, 2005; Lanza & Marinescu, 2006]. Marinescu (2004) chama esse mecanismo de estratégias de detecção. Estratégias de detecção ajudam os desenvolvedores a detectar e localizar problemas de design de um software. Uma estratégia de detecção é uma condição lógica composta por métricas que detecta elementos do design com problemas específicos. Por
meio do uso de estratégias de detecção, o desenvolvedor pode localizar diretamente classes e métodos afetados por um problema de design particular, em vez de ter que inferir o problema a partir de um extenso conjunto de valores anormais de métricas. Este mecanismo vem sendo cada vez mais explorado. Recentemente foi publicado um livro sobre o assunto [Lanza & Marinescu, 2006]. Além disso, foi desenvolvida uma ferramenta [inCode, 2008] que automatiza o uso de algumas estratégias de detecção para a identificação de anomalias de design OO recorrentes, como os chamados “bad smells” [Fowler et al, 1999].
A maioria dos trabalhos realizados até hoje propõem ou estudam estratégias de detecção com base exclusivamente em informações do código fonte. No entanto, detectar e corrigir problemas de design apenas depois de se investir na implementação do sistema pode ser caro e impraticável. Além disso, com o aumento da importância da engenharia de software dirigida por modelos, a detecção de anomalias de design precisa ser realizada desde as representações de mais alto nível do sistema, como por exemplo, diagramas UML. Existem trabalhos que definem métricas para diagramas de classes [Genero et al, 2002; Tang & Chen, 2002] e ferramentas que automatizam a aplicação destas métricas [SDMetrics, 2008; MetricView, 2005]. Porém, esses trabalhos não se dedicam à utilização de estratégias de detecção e, por isso, suas métricas sofrem das mesmas limitações das métricas de código.
É importante, portanto, definir estratégias de detecção que possam ser aplicadas a modelos. Além disso, é preciso avaliar se essas estratégias são capazes de identificar os mesmos elementos problemáticos do design que as estratégias de detecção aplicadas ao código identificam. Nesse contexto, definimos nesse trabalho duas estratégias de detecção a serem aplicadas a diagramas de classes. Mais especificamente, definimos as versões para modelos das estratégias definidas por Lanza & Marinescu (2006) para a detecção no código dos problemas de design chamados de god class [Riel, 1996] e data class [Fowler et al, 1999]. Além disso, realizamos um estudo experimental para verificar a acurácia dessas duas estratégias aplicadas a modelos. Em outras palavras, as contribuições desse trabalho são: (i) a adaptação de duas estratégias de detecção para serem aplicadas em modelos e (ii) a realização de um estudo para verificar o grau de acurácia com o qual cada estratégia para modelos detecta as mesmas classes que sua estratégia correspondente para código. O estudo mostrou que os resultados da aplicação das estratégias nos diagramas de classes têm elevada acurácia quando comparados com os resultados da aplicação das estratégias no código.
O restante do texto está organizado da seguinte forma. A Seção 2 descreve as estratégias de detecção de god class e data class para código propostas por Lanza & Marinescu (2006). A Seção 3 descreve como adaptamos essas estratégias para serem aplicadas em diagramas de classes. A Seção 4 detalha o estudo experimental realizado. Os resultados do estudo são discutidos na Seção 5. Finalmente, na Seção 6 são apresentadas as conclusões junto com os trabalhos futuros.
2. Estratégias para a Detecção de Problemas de Design
Esta seção descreve as estratégias para detecção de god class e data class para código fonte usadas no estudo experimental. Essas duas estratégias de detecção foram selecionadas para esse primeiro estudo porque, das estratégias automatizadas pela ferramenta inCode [inCode, 2008], são as únicas que fazem sentido serem aplicadas
também em diagramas UML. As outras estratégias implementadas por inCode se baseiam em informações que podem ser obtidas exclusivamente no código fonte. Achamos mais confiável usar a ferramenta inCode no nosso estudo por ela ter sido desenvolvida pelo mesmo grupo que definiu as estratégias de detecção para código utilizadas neste trabalho. As estratégias de detecção baseadas em métricas utilizam valores limites a fim de detectar as classes que apresentam problemas de design. Os valores limites usados nas estratégias para código foram definidos em [Lanza & Marinescu, 2006] com base em estudos empíricos por eles realizados.
God Class. Esse problema de design se refere às classes que tendem a centralizar a
maioria do trabalho de um sistema [Riel, 1996]. Ao fazer isso, uma instância de uma god class usa dados de várias outras classes e delega apenas detalhes do trabalho a essas classes [Riel, 1996]. Lanza & Marinescu (2006) definem a estratégia para a detecção de classes com essa anomalia com base em três características prováveis dessas classes: (i) elas acessam muitos dados de outras classes, (ii) elas são grandes, e (iii) tem muitos métodos que não interdependem (baixa coesão). A estratégia para detecção de god class é definida da seguinte forma [Lanza & Marinescu, 2006]:
God Class = (ATFD > 4) and (WMC >= 47) and (TCC < 0,33),
em que: (i) a métrica ATFD (Access To Foreign Data) conta o número de atributos de outras classes acessados pela classe avaliada, (ii) a métrica WMC (Weighted Method per Class) é a soma das complexidades de todos os métodos de uma classe (Lanza & Marinescu usam a métrica de complexidade ciclomática de McCabe (1976) para calcular a complexidade dos métodos), e (iii) a métrica TCC (Tight Class Cohesion) conta o número relativo de métodos de uma classe que acessam pelo menos um atributo em comum. Os detalhes de implementação e as referências originais dessas métricas podem ser encontrados em [Lanza & Marinescu, 2006].
Data Class. Este problema de design corresponde a classes que não definem
funcionalidade própria [Fowler et al, 1999]. A falta de métodos funcionais nessas classes pode indicar que o comportamento relacionado aos seus dados não está localizado em um único lugar. Uma instância de uma data class normalmente possui atributos e métodos de acesso que são utilizados por muitas outras classes. Lanza & Marinescu (2006) definem a estratégia para a detecção de classes com esta anomalia com base nas seguintes características prováveis dessas classes: (i) suas interfaces oferecem muitos dados e poucos serviços e (ii) elas possuem muitos atributos, mas são pouco complexas. A estratégia para a detecção de data class é definida da seguinte forma [Lanza & Marinescu, 2006]:
Data Class = (WOC < 0,33) and (((NOPA+NOAM > 4) and (WMC < 47)) or ((NOPA+NOAM > 2) and (WMC < 31))),
em que: (i) a métrica WOC (Weight Of Class) conta a porcentagem de métodos correspondentes aos serviços oferecidos pela classe em relação ao total de métodos que ela possui, (ii) a métrica WMC é computada da mesma forma apresentada anteriormente para god class, (iii) a métrica NOPA (Number Of Public Attributes) conta o número de atributos públicos de uma classe, e (iv) a métrica NOAM (Number Of Access Methods) conta o número de métodos de acesso não herdados que uma classe possui. Marinescu identifica estes métodos como aqueles cujo nome tem como prefixo ‘get’ ou ‘set’ e cuja
complexidade ciclomática tem valor um. Os detalhes de implementação e as referências originais dessas métricas podem ser encontrados em [Lanza & Marinescu, 2006].
3. Estratégias para a Detecção de Problemas de Design em modelos UML
Com o objetivo de antecipar a detecção de problemas de design desde os modelos do sistema, adaptamos um conjunto de estratégias de detecção a fim de permitir que elas sejam aplicadas em diagramas UML, mais especificamente a diagramas de classes. A idéia é que estratégias de detecção originalmente definidas com base em informações disponíveis no código fonte, possam ser usadas apenas com informações disponíveis nos diagramas de classes. Além de definir tais estratégias baseadas em modelos, desenvolvemos uma ferramenta para automatizar sua aplicação. A Seção 3.1 apresenta as estratégias de detecção de god class e data class adaptadas para aplicação em diagrama de classes. A Seção 3.2 descreve brevemente a ferramenta que automatiza a aplicação dessas estratégias e que foi usada no estudo experimental.
3.1. Detecção de God Class e Data Class em Diagramas de Classes
Esta seção descreve as adaptações realizadas nas estratégias de detecção de god class e data class para que elas possam ser aplicadas em diagramas de classes. As adaptações foram de dois tipos: (i) substituição de métricas baseadas em informações existentes apenas no código fonte por métricas semelhantes baseadas em informações disponíveis em diagramas de classes, e (ii) mudança na forma de computar algumas métricas. Os valores limites foram usados nas estratégias para modelos com base nos valores limites das estratégias para código correspondentes: (i) mesmos valores para as métricas cuja informação necessária para seu cálculo está disponível no modelo em nível de detalhe semelhante ao do código, e (ii) valores limites menores para as métricas cuja informação necessária para seu cálculo está disponível no modelo em menor detalhe que no código. Os valores limites precisam ser mais testados e podem ser modificados no futuro.
God Class. As três métricas usadas na estratégia de detecção de god class para código (Seção 2) – ATFD, WMC e TCC – dependem de informações disponíveis exclusivamente no código interno dos métodos, respectivamente, para: (i) determinar os atributos de outras classes acessados pelos métodos, (ii) calcular a complexidade ciclomática [McCabe, 1976] dos métodos, e (iii) calcular a coesão de uma classe com base nos atributos acessados por cada método. Como essas informações não estão disponíveis em diagramas de classes, tivemos que realizar adaptações para definir a estratégia de detecção de god class para modelos. Primeiro, substituímos a métrica TCC pela métrica CAM (Cohesion Among Methods) [Bansiya & Davis, 1999]. CAM calcula a coesão de uma classe com base na quantidade de pares de métodos que possuem parâmetros do mesmo tipo. Na implementação dessa métrica consideramos apenas os tipos definidos pelos usuários. Segundo, no cálculo de WMC, passamos a considerar que todos os métodos têm valor de complexidade igual a um. E por último, na computação de ATFD, consideramos apenas referências a outras classes realizadas nas declarações de atributos e parâmetros, além de associações e dependências entre classes. Além disso, ATFD no código conta o número de atributos acessados, enquanto, no modelo, conta apenas o número de classes referenciadas. Dessa forma, a estratégia de detecção de god class para modelos ficou da seguinte forma:
God Class = (ATFDadpt > 4) and (WMC1 >= 25) and (CAM < 0,33),
em que ATFDadpt refere-se à métrica ATFD adaptada e WMC1 refere-se a WMC com valor de complexidade dos métodos igual a um.
Data Class. Aqui três das quatro métricas utilizadas na estratégia de detecção de data
class para código (Seção 2) – WOC, NOAM, WMC – dependem de informações disponíveis no código interno dos métodos para: (i) determinar quais são os métodos de acesso, e (ii) calcular a complexidade ciclomática dos métodos. Ao realizar as adaptações simplificamos a identificação dos métodos de acesso para a computação das métricas WOC e NOAM: a complexidade cliclomática não é mais levada em conta. Agora os métodos de acesso são aqueles que: (i) têm prefixo “get” e retornam algum valor, ou (ii) têm prefixo “set” e não retornam valor. Além disso, na computação de WMC, o valor da complexidade de um método é o número de seus parâmetros. Essa última adaptação tem como base o fato de que instâncias de data class oferecem muitos dados e poucos serviços, e, portanto, seus métodos normalmente possuem poucos parâmetros. Não foi necessário adaptar a métrica NOPA. Sendo assim, a estratégia de detecção de data class para modelos ficou da seguinte forma:
Data Class = (WOCadpt < 0.33) and (((NOPA+NOAMadpt > 4) and (WMCparam <
4)) or ((NOPA+NOAMadpt > 2) and (WMCparam < 3))),
em que: WOCadpt, e NOAMadpt referem-se as métrica WOC e NOAM adaptadas, e WMCparam refere-se a WMC com valor de complexidade dos métodos igual ao número
de parâmetros.
3.2. Ferramenta
A ferramenta é composta por três módulos: (i) importação de diagramas de classes, (ii) aplicação das métricas e (iii) aplicação das estratégias de detecção. O módulo de importação de diagramas de classes recebe como entrada arquivos XMI [XMI, 2000] que descrevem os modelos UML que representam o design dos sistemas a serem avaliados. Esses arquivos XMI são normalmente gerados por ferramentas de modelagem UML. A ferramenta analisa a informação contida nesses arquivos e gera a representação do diagrama de classes em uma estrutura de dados apropriada para aplicação das métricas. Depois de importado o diagrama de classe de um sistema, o módulo de aplicação das métricas é responsável por calcular os valores das métricas. Esses valores são armazenados de tal forma que possam ser usados na computação das estratégias de detecção e/ou exportados em arquivo texto. Finalmente, o módulo de aplicação de estratégias de detecção usa os valores das métricas para classificar as classes do diagrama de acordo com as estratégias de detecção implementadas. Como resultado, a ferramenta apresenta uma tabela com os nomes das classes detectadas por cada estratégia.
4. Estudo Experimental
O objetivo do estudo experimental foi avaliar com que grau de acurácia as duas estratégias de detecção para modelos propostas (Seção 3) detectam as mesmas classes com problemas de design que sua estratégia correspondente para código. O estudo se baseou na estrutura proposta por Wohlin et al (2000).
4.1. Definição do Estudo
Analisar: as estratégias de detecção god class e data class para modelos Com o propósito de: avaliar
Com respeito a: sua acurácia para detectar as mesmas classes com problemas de design que as estratégias de detecção para código
Do ponto de vista: do pesquisador
No contexto de: estudantes da pós-graduação do Laboratório de Engenharia de Software da PUC-Rio.
4.2. Planejamento
Contexto da seleção. O estudo supõe o processo off-line e é classificado como quase-experimento, pois apresenta ausência de randomização tanto na seleção dos objetos quanto na seleção dos participantes. A realização do estudo envolveu apenas um estudante de mestrado na área de engenharia de software da PUC-Rio.
Formulação das hipóteses. Para a definição das hipóteses usamos o verbo “classificar” com o significado de “decidir se uma classe possui o problema de design ou não”. Temos, então, dois pares de hipóteses, cada um associado a uma estratégia de detecção:
God Class
― Hipótese nula (H0): A estratégia de detecção god class para modelos não classifica as classes de forma semelhante a sua homóloga para código fonte.
― Hipótese alternativa (H1): A estratégia de detecção god class para modelos classifica as classes de forma semelhante a sua homóloga para código fonte.
Data Class
― Hipótese nula (H0): A estratégia de detecção data class para modelos não classifica as classes de forma semelhante a sua homóloga para código fonte.
― Hipótese alternativa (H1): A estratégia de detecção data class para modelos classifica as classes de forma semelhante a sua homóloga para código fonte.
Seleção das variáveis. Esse estudo procura verificar se, quando o conjunto de classes detectadas no modelo varia, o conjunto de classes detectadas no código acompanha essa variação. A variável dependente corresponde, portanto, às classes detectadas como suspeitas de serem instâncias de data class/god class pelas estratégias de detecção para código. A variável independente corresponde às classes detectadas como suspeitas de serem instâncias de data class/god class pelas estratégias de detecção para modelos.
4.3. Operação
Preparação. O contexto deste estudo envolveu um conjunto de nove sistemas: um
framework para a geração de relatórios estatísticos para o gerenciamento de incidentes (S1), um framework para o gerenciamento de conteúdos (S2), uma linha de produto de software de locadora de filmes (S3), um framework para a aplicação de métricas no código fonte (S4), uma ferramenta para a aplicação das estratégias de detecção em diagramas de classes (S5) e as versões 5.2 (S6), 6.0 (S7), 7.0 (S8) e 7.1 (S9) do sistema open source JHotdraw [JHotdraw, 2008]. A escolha destes sistemas foi feita por conveniência. Procurou-se por sistemas nos quais a documentação e os diagramas de
classes estivessem disponíveis. Os primeiros quatro sistemas foram desenvolvidos como trabalho da disciplina de Projeto de Sistemas de Software do programa de pós-graduação em informática da PUC-Rio. O quinto sistema é a ferramenta descrita na Seção 3.2. Para as diferentes versões do sistema JHotdraw os diagramas de classes foram gerados mediante engenharia reversa apoiada pela ferramenta Enterprise Architecture [EA, 2008]. Além disso, algumas das relações entre as classes foram geradas manualmente pelo estudante de mestrado. Todos os sistemas foram desenvolvidos utilizando a linguagem de programação Java e suas características são apresentadas na Tabela 1.
Execução. A execução do estudo pode ser resumida nos seguintes passos: (i) aplicação das estratégias de detecção nos diagramas de classes usando nossa ferramenta (Seção 3.2), (ii) aplicação das estratégias de detecção no código utilizando a ferramenta inCode [inCode, 2008], e (iii) análise dos resultados com base no cálculo da acurácia.
Tabela 1 - Características dos sistemas utilizados no estudo
Sistema Num. Pacotes Num. Classes Num. Métodos Num. Atributos
S1 12 61 513 142 S2 38 102 529 218 S3 27 110 898 194 S4 18 96 459 248 S5 16 150 679 459 S6 17 172 1.438 363 S7 16 332 3.117 361 S8 21 313 3.251 735 S9 25 401 3.986 1.198 4.4. Análise e Interpretação
Os resultados da aplicação das estratégias de detecção nos sistemas avaliados estão resumidos na Tabela 2. A tabela apresenta o número de classes detectadas pelas estratégias como suspeitas de possuir os problemas de design. A Tabela 2 também apresenta o grau de acurácia das estratégias para modelos em cada um dos sistemas.
Tabela 2 - Resultado das estratégias de detecção propostas
Data Class God Class
Sistemas Total de suspeitos no modelo Total de suspeitos no código FP FN Acurácia Total de suspeitos no modelo Total de suspeitos no código FP FN Acurácia S 1 12 10 2 0 96% 0 0 0 0 100% S 2 5 4 1 0 99% 0 1 0 1 99% S 3 17 15 2 0 98% 3 0 3 0 97% S 4 16 14 2 0 97% 1 0 1 0 99% S 5 14 11 3 0 98% 0 1 0 1 99% S 6 2 1 1 0 99% 2 0 2 0 98% S 7 5 3 2 0 99% 3 1 2 0 99% S 8 8 6 2 0 99% 5 8 1 3 98% S 9 16 13 3 0 99% 5 3 3 1 99%
Para o cálculo da acurácia, as classes classificadas pelas estratégias em cada sistema são categorizadas da seguinte forma: Falsos Positivos (FP) incluem todos os suspeitos revelados no modelo que não foram detectados no código; Falsos Negativos (FN) referem-se a todas as classes que não foram classificadas como suspeitas no modelo, porém, foram identificadas no código; Verdadeiros Positivos (VP) incluem todos os suspeitos no modelo que foram detectados também no código; e Verdadeiros
Negativos (VN) referem-se às classes não identificadas no modelo nem no código. A acurácia de cada estratégia de detecção em cada sistema é então calculada da seguinte forma: Acurácia = FN FP VN VP VN VP + + +
+ . As estratégias de detecção propostas, data
class e god class, apresentaram graus de acurácia acima de 95% para todos os sistemas avaliados (Tabela 2). A partir desses elevados valores de acurácia, pode-se então rejeitar as hipóteses nulas formuladas na Seção 4.2 tanto para god class quanto para data class.
4.4. Validação da análise
O único aspecto que ameaça a validade de conclusão de nosso estudo é o tamanho da amostra, que é provavelmente pequeno. Estamos cientes disso e, portanto, consideramos os resultados apenas como preliminares. As ameaças à validade de construção são mínimas porque a computação das estratégias de detecção tanto para modelos como para código foi totalmente automatizada. A principal ameaça à validade interna do estudo está relacionada ao grau de correspondência entre os diagramas e código. Para minimizar essa ameaça, nos preocupamos com os seguintes pontos: (i) os diagramas dos sistemas S1 a S5 foram gerados pelos próprios desenvolvedores como parte do processo de desenvolvimento e dentro do contexto de disciplinas que avaliavam a correspondência dos modelos com o código, (ii) os diagramas de classes dos sistemas S6 a S9 (versões do JHotdraw) foram gerados com o apoio a ferramenta Enterprise Architecture [EA, 2008]. Além disso, a geração de algumas relações nos diagramas de classes das versões do JHotdraw foram geradas manualmente pelo estudante de mestrado. O estudante possui bons conhecimentos e experiência sobre modelagem orientada a objetos. Além disso, visando evitar sua fadiga e desinteresse, o estudante dedicou a essa tarefa aproximadamente uma hora por dia durante trinta dias. A principal ameaça à validade externa do nosso estudo é a natureza dos sistemas analisados. Para minimizar essa ameaça procuramos usar sistemas de tamanhos diferentes e desenvolvidos por pessoas e ambientes (academia e open-source) distintos. Porém, estamos cientes que mais estudos experimentais evolvendo sistemas comerciais devem ser realizados no futuro.
5. Discussão
A tabela 2 também apresenta o número de falsos positivos e falsos negativos encontrados. God class apresentou casos de falsos positivos e falsos negativos. Data class apresentou apenas casos de falsos positivos, porém em todos os sistemas. Nesta seção são discutidas as principais causas desses falsos positivos e falsos negativos. Falsos positivos para data class. Os casos de falsos positivos para a estratégia de data
class ocorreram porque as métricas da versão para modelos dessa estratégia foram adaptadas de forma a usar menos informações que as correspondentes da versão para código. Por exemplo, uma das cláusulas dessa estratégia diz que, para ser uma data class, uma classe tem que ter NOPA+NOAM > 4 (Seção 2). A métrica NOAM conta o número de métodos de acesso de uma classe. Dentre outras coisas, essa métrica usa a complexidade do método para decidir se ele é de acesso ou não. Se a complexidade do método é alta, ele não é considerado como de acesso. No código, a complexidade do método é sua complexidade ciclomática. No entanto, como no modelo não há informações para cálculo da complexidade ciclomática, a complexidade de todos os
métodos foi fixada com o valor um (NOAMadpt). Por causa disso, alguns métodos foram
classificados como de acesso no modelo, mas não o foram no código. Isso fez com que algumas classes tivessem valor maior para NOAM no modelo, e conseqüentemente, fossem classificadas como data class no modelo e não no código. Situações semelhantes ocorreram também com relação à métrica WOCadpt (Seção 3.1). Essa forma de
adaptação da estratégia data class também explica a ausência de falsos negativos. Além disso, a própria existência de menos informação nos diagramas de classes contribuiu para falsos positivos. Por exemplo, no código, a computação de NOAM para classes de negócio não leva em conta alguns métodos por eles serem herdados de classes de APIs. Porém, as classes de APIs não foram consideradas nos modelos. Por isso, a computação de NOAM nos modelos não sabe que tais métodos foram herdados. Isso contribuiu para diferenças nos valores dessa métrica, e, conseqüentemente, falsos positivos.
Falsos positivos para god class. No caso da estratégia de god class, os falsos positivos foram causados pelo uso, na estratégia para modelos, da métrica de coesão CAM no lugar da métrica TCC, usada na estratégia para código. Algumas classes do modelo tiveram valores altos para a métrica CAM, enquanto TCC apresentou valores baixos para as mesmas classes no código. Isso levou algumas dessas classes a serem classificadas como god class no modelo e não no código, uma vez que uma das cláusulas dessa estratégia diz que para ser god class uma classe tem que ter coesão maior que 0,33. Note que a diferença na forma de calcular coesão dessas duas métricas poderia também levar a casos em que uma mesma classe tivesse valor alto de CAM e valor baixo de TCC. Isso poderia contribuir para a ocorrência de falsos negativos. Porém, não houve exemplos desse caso nos sistemas avaliados nesse estudo.
Falsos negativos para god class. Os casos de falsos negativos para a estratégia de god
class foram causados pela adaptação das métricas WMC e ATFD. Uma das cláusulas dessa estratégia diz que, para ser god class, uma classe tem que ter WMC > 47 (Seção 2). WMC mede a soma das complexidades de todos os métodos de uma classe. Novamente, as diferenças ocorreram porque no código a complexidade de um método corresponde a sua complexidade ciclomática, enquanto no modelo a complexidade de cada método foi fixada em um. Houve casos de classes com poucos métodos com alta complexidade ciclomática. Essas classes apresentaram valor alto de WMC no código, mas valor baixo no modelo, gerando, então, falsos negativos. Em relação à métrica ATFD, a estratégia diz que para ser god class uma classe deve ter ATFD > 4 (Seção 2). No modelo, ATFD conta apenas o número de classes acessadas e não o número de atributos acessados, como é feito no código. Por isso, algumas classes apresentaram valores altos de ATFD no código e baixos no modelo, o que contribuiu para alguns casos de falsos negativos.
6. Conclusões e Trabalhos Futuros
Neste artigo apresentamos duas estratégias de detecção para a identificação de problemas de design em diagramas de classes, com objetivo de ajudar os projetistas a diminuir a quantidade de correções de defeitos em etapas posteriores. A aplicação automatizada destas estratégias de detecção foi apoiada pela ferramenta apresentada na Seção 3.1. Realizamos um estudo experimental (Seção 4) para verificar o grau de acurácia com que cada estratégia para modelos detecta as mesmas classes que sua estratégia correspondente para código. Embora preliminares, os resultados do estudo
mostraram que a aplicação das estratégias god class e data class nos diagramas de classes detectam um conjunto de classes bem semelhante ao detectado pelas estratégias de detecção correspondentes para código definidas em [Marinescu, 2004; Lanza & Marinescu, 2006]. Isto indica que as estratégias de detecção propostas neste trabalho para diagramas de classes, a princípio, podem ser utilizadas como ajuda aos projetistas para construir um melhor software, diminuindo as correções desnecessárias e potenciais defeitos em etapas posteriores. Pretendemos no futuro realizar esse mesmo tipo de estudo mais aprofundado envolvendo um maior número de sistemas e outras estratégias de detecção cuja aplicação em diagramas de classes já é automatizada por nossa ferramenta.
Agradecimentos. A realização desse trabalho tem apoio da CAPES e da FAPESB.
Referências
Bansiya, J.; Davis, C. G. Class Cohesion Metric for Oriented Designs. J. Object-Oriented Programming, 11(8), p. 47-52, janeiro 1999.
EA. Enterprise Architecture. Disponível em <http://www.sparxsystems.com.au/>. Acesso em: janeiro 2008.
Emden, E.; Moonen, L. Java quality assurance by detecting code smells. In Proc. 9th Working Conf. Reverse Engineering, IEEE Computer Society, pp. 97-107, outubro 2002. Fowler, M. et al. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999. Genero, M. et al. Empirical validation of class diagram metrics. In Proceedings of Int’l
Symp. on Empirical Software Engineering, Nara, Japan, p.195-203, outubro 2002. inCode. 2008. Disponivel em <http://loose.upt.ro/incode>. Acesso em: agosto 2008. JHotdraw. Disponivel em <http://www.jhotdraw.org/>. Acesso em: maio 2008.
Lanza, M.; Marinescu, R. Object-Oriented Metrics In Practice: Using Software Metrics to Characterize, Evaluate, and Improve the Design of Object-Oriented Systems. Springer-Verlag Berlin And Heidelberg Gmbh & Co. Kg (Alemanha), 2006
Marinescu, R. Detection Strategies: Metric-Based Rules for Detecting Design Flaws. IEEE International Conference, p. 350-359, 2004.
Martin, R. Agile Software Development, Principles, Patterns, and Practices. Prentice Hall, 2002.
McCabe, T. J. A Complexity Measure. IEEE Transactions on Software Engineering, 2(4), p 308-320, dezembro 1976.
MetricView 2005. Disponível em: <http://www.win.tue.nl/empanada/>. Acesso em: abril 2008. Munro, M. J. Product Metrics for Automatic Identification of “Bad Smells” Design
Problems in Java Source- Code. IEEE International Conference, 2005.
Riel, A. J. Object–Oriented Design Heuristics. Addison–Wesley, first edition, 1996.
Sahraoui, H.; Boukadoum, M.; Lounis, H. Building Quality Estimation models with Fuzzy
Threshold Values. L’Objet, 17(4), p. 535-554, 2001.
SDMetrics. Disponível em: <http://www.sdmetrics.com/>. Acesso em: maio 2008.
Tang, M.; Chen, M. Measuring OO Design Metrics from UML. Springer Berlin / Heidelberg. p. 361-370, janeiro 2002.
Wohlin, C. et al. Experimentation in Software Engineering: An Introduction, Kluwer Academic Publishers, 2000.
