• Nenhum resultado encontrado

Integração de Métricas Estáticas e Dinâmicas para apoiar a Avaliação da Qualidade em Modelos de Software

N/A
N/A
Protected

Academic year: 2021

Share "Integração de Métricas Estáticas e Dinâmicas para apoiar a Avaliação da Qualidade em Modelos de Software"

Copied!
8
0
0

Texto

(1)

Integração de Métricas Estáticas e Dinâmicas para

apoiar a Avaliação da Qualidade em Modelos de Software

Deivison Barreto, Mara Barcelos, Aline Vasconcelos

Instituto Federal de Educação, Ciência e Tecnologia Fluminense (IFF) NES (Núcleo de Engenharia de Software)

Rua Dr. Siqueira, nº. 273 – 28.030-130 – Campos dos Goytacazes – RJ – Brasil

deivisonlb@gmail.com, {mrbarcelos,apires}@iff.edu.br Abstract. This work presents a proposal for integration of static and

dynamic metrics, since measurement is one way to evaluate software quality Generally, these types of metrics are used in isolation, but their integration allows the analysis to be carried out more widely, because it can take into consideration characteristics of both types of analysis. This fact provides a more complete view of the product, still during analysis phase, making clear its understanding. Therefore, indicators of required improvements can be obtained, thus contributing to increased software quality.

Resumo. O presente trabalho apresenta uma proposta de integração

de métricas estáticas e dinâmicas, visto que a medição é uma forma de se avaliar a qualidade do software. Na maioria das vezes, esses tipos de métricas são utilizados de forma isolada, mas sua integração permite que a análise seja realizada de forma mais ampla, pois leva em consideração características de ambos os tipos de análise. Tal fato proporciona uma visão mais completa do produto, ainda na fase de modelagem, tornando mais claro o seu entendimento. Assim, indicadores de melhorias podem ser obtidos, no início do ciclo de vida, contribuindo para a melhoria da qualidade do software.

1. Introdução

Segundo Rockenbach (2003), o processo de medição é uma parte importante na Engenharia de Software (ES), pois através dele são obtidas informações concretas sobre processos e produtos, o que auxilia na tomada de decisões, proporcionando uma melhoria na qualidade e produtividade de software. Métricas de processo podem indicar o desempenho da equipe, atrasos no cronograma, custos etc. Em relação às métricas de produto, podem ser obtidas métricas estáticas ou dinâmicas, do modelo ou do código, que oferecem indicadores sobre a sua qualidade. Os autores Chidamber e Kemerer (1994) e Lorenz e Kidd (1994) tratam de métricas estáticas, enquanto os autores Erik Arisholm (2002) e Yacoub et al. (1999) tratam das métricas dinâmicas.

O paradigma de programação é uma característica que mostra a importância de realizar a combinação de métricas estáticas e dinâmicas. Segundo Pressman (2007), o princípio básico da programação estruturada é q u e os programas são formados a partir de um conjunto de construções lógicas como sequência, condição e repetição. Já no paradigma de Orientação a Objetos (OO), os sistemas possuem características como: organização em classes, que por sua vez, instanciam objetos que trocam mensagens entre si; relacionamentos estáticos, além dos dinâmicos, sendo esses últimos estabelecidos quando os objetos trocam mensagens durante a execução do

(2)

software; vinculação tardia (late binding); herança e polimorfismo, onde só se define o objeto que recebe de fato uma chamada de método em tempo de execução. Uma característica que pode ser identificada de forma clara através da análise estática do modelo é a herança, em virtude da qual, existe o polimorfismo, que é a capacidade de um objeto alterar seu comportamento em tempo de execução, sendo possível, somente através da análise dinâmica, identificar o tipo correto de um determinado objeto e o volume de mensagens trocadas entre objetos específicos.

Segundo Vasconcelos (2007), as métricas estáticas possuem grande importância na verificação da qualidade de software, entretanto, as características presentes no paradigma OO justificam a utilização de métricas estáticas e dinâmicas, uma vez que muitas dessas características não são observadas quando é feita apenas a análise estática. As métricas estáticas são extraídas através de modelos estáticos, como, por exemplo, o modelo de classes, enquanto as métricas dinâmicas são extraídas de modelos comportamentais, como os diagramas de sequência, o que pode ser feito em tempo de modelagem ou de execução. Nesse contexto, este trabalho tem como objetivo a combinação das métricas estáticas e dinâmicas para sistemas OO, extraídas em nível de modelo, o u s ej a, no i ní ci o do ci cl o de vi d a d o s o f t war e, o que pode trazer maior contribuição para verificação de possíveis problemas, contribuindo de forma efetiva com a melhoria da qualidade.

Em relação aos ambientes e ferramentas existentes, a maioria extrai apenas métricas de uma dessas categorias e não atende plenamente outras características importantes, como ser livre e genérica. Exemplos de algumas dessas ferramentas são: JProfiler [EJ - TECHNOLOGIES 2010], que extrai métricas dinâmicas em tempo de execução e o SDMetrics (2009), utilizado na medição da qualidade de modelos UML. Neste trabalho, a ferramenta XMIMetricsTool [BARCELOS e SILVA, 2009] é estendida, a fim de incorporar a combinação de métricas estáticas e dinâmicas.

Além dessa Introdução, este artigo está organizado da seguinte forma: a Seção 2 aborda métricas de modelos; a Seção 3 apresenta a proposta de combinação de métricas estáticas e dinâmicas para modelos OO, a ferramenta estendida para esta finalidade e um exemplo de sua utilização; a Seção 4 apresenta os trabalhos relacionados; e, a Seção 5 apresenta as conclusões e trabalhos futuros.

2. Métricas de Modelo

Métricas de software são indicadores quantitativos obtidos através da coleta de dados referentes à qualidade e produtividade de um software [VIEIRA NETO 2008]. A medição pode ser definida como o processo através do qual símbolos ou números são atribuídos aos atributos de uma entidade do mundo real, de forma a descrevê -la de acordo com regras claras e bem definidas [FENTON e PFLEEGER 1997]. O processo de medição pode ser realizado tanto no produto, quanto no processo.

As métricas de processo são um conjunto de teorias e práticas que se relacionam com medidas, permitindo assim, realizar uma estimativa de custo, desempenho e cronograma de um projeto, a fim de verificar os critérios de qualidade que devem ser atingidos [BARCELOS e SILVA 2009]. As métricas de produto (também conhecidas como métricas de qualidade) podem ser extraídas através do modelo ou do código. Elas têm como objetivo medir a qualidade dos sistemas desenvolvidos em um determinado momento, seja na fase de desenvolvimento, ou na fase de manutenção, quando o

(3)

processo de desenvolvimento estiver finalizado. A análise dos resultados obtidos através do processo de medição auxilia na tomada de decisão, pois possibilita a verificação de alterações que precisam ser realizadas. A extração de métricas de modelo permite a identificação precoce de possíveis erros, evitando que eles se propaguem para a fase de codificação, o que reduz o custo de sua correção [VASCONCELOS 2007].

Em relação às métricas estáticas de modelo ou de código, podem ser citadas como exemplo as propostas por Chidamber e Kemerer (1994): DIT (Depth of

Inheritance Tree - Profundidade da Árvore de Herança); NOC (Number of Children -

Número de Filhos); CBO (Coupling between Object Classes - Acoplamento entre Classes de Objetos), dentre outras. Lorenz e Kidd (1994), autores que também são bastante referenciados na literatura, propuseram métricas como: NPM (Number of

Public Methods - Número de Métodos Públicos); NM (Number of Methods - Número

de Métodos); NPV (Number of Public Variables per Class - Número de Atributos Públicos) e NV (Number of Variables per Class - Número de Atributos de uma Classe).

Dentre as métricas citadas, é importante destacar a métrica CBO, pela sua relevância para o presente trabalho. Esta métrica contabiliza os relacionamentos estáticos que cada classe possui, como associações, dependências, agregações e composições, sendo necessário ressaltar que a herança não conta como relacionamento, entretanto, os relacionamentos herdados são contabilizados. Quanto mais acoplada uma classe estiver à outra, maiores são as suas dependências e a possibilidade de ocorrência de efeitos colaterais durante as manutenções [VASCONCELOS 2007].

Erik Arisholm (2002) afirma que uma maneira comum de quantificar o acoplamento ocorre através da análise estática do modelo ou do código, mas que existem certos comportamentos do software que não podem ser capturados através da análise estática. Tais comportamentos e aspectos somente podem ser capturados através da análise dinâmica, ou seja, pelo fluxo das mensagens trocadas entre objetos, as quais são representadas através dos diagramas de sequência. Por exemplo, devido às características como herança e polimorfismo, nem sempre é possível, através da análise estática, determinar exatamente quais são as classes receptoras e remetentes das mensagens trocadas entre os objetos, porém, é possível obter essas informações através da análise dinâmica, feita através de modelos comportamentais.

3. Proposta de Combinação de Métricas

3.1. Abordagem Proposta

A abordagem proposta neste trabalho é a combinação de visões de diferentes autores sobre métricas de software, de modo a trazer melhorias para a avaliação da sua qualidade. Para realizar tal abordagem, algumas métricas e diagramas da UML foram utilizados, de acordo com as suas características e relevância para o tema proposto. Uma dessas características é o acoplamento entre classes, o que motivou a escolha da métrica CBO dos autores Chidamber e Kemerer (1994). É a partir da contagem dos relacionamentos estáticos obtidos através da aplicação dessa métrica que foi realizada a combinação das métricas estáticas e dinâmicas. Dizer que duas ou mais classes são altamente acopladas significa que a dependência entre elas é muito grande. Reduzir o acoplamento pode minimizar impactos de manutenção. Se uma alteração é feita em uma dessas classes, as demais classes também tendem a sofrer alterações, o que muitas vezes pode ocorrer indevidamente. Como o alto acoplamento diminui o potencial de

(4)

reuso e a manutenibilidade das classes, melhorias em sua verificação podem auxiliar na identificação de possíveis problemas no software.

Entretanto, a CBO é uma métrica estática, ou seja, ela representa aquilo que pode acontecer em um sistema, mas não significa que acontecerá de fato, o que motiva a combinação das análises estática e dinâmica. Por exemplo, uma classe pode estar acoplada a outra estaticamente, mas nunca trocar mensagens com ela, ou seja, essa classe nunca envia ou requer algum serviço da outra classe. O fato dessas classes não trocarem mensagens não é identificado através da análise de um diagrama de classes, entretanto, é possível identificá-lo através da análise de diagramas de sequência, observando-se, por exemplo, a força de acoplamento [ERIK ARISHOLM 2002], que representa a quantidade de associações entre os papéis em um cenário de execução do software, ou seja, a quantidade das mensagens trocadas entre objetos das classes.

A XMIMetricsTool é uma ferramenta de cálculo de métricas através do modelo, apresentada por Barcelos e Silva (2009). Desenvolvida para apoiar a garantia da qualidade de software desde o início do seu ciclo de vida, identificando possíveis erros antes que eles possam ser propagados para o código, ela realiza o cálculo de métricas dos autores Chidamber e Kemerer (1994) e Lorenz e Kidd (1994). Neste trabalho, foram acrescentadas à XMIMetricsTool, métricas dinâmicas que contabilizam as mensagens trocadas entre as classes, referente ao conceito de força de acoplamento.

A direção do acoplamento varia de acordo com a direção da mensagem emitida e recebida [ERIK ARISHOLM 2002]. Quando uma classe envia uma mensagem, ela está importando acoplamento, enquanto uma classe que recebe uma mensagem exporta acoplamento, visto que outra classe (a que enviou a mensagem) se tornou dependente de sua resposta. A contabilização tanto das mensagens que contribuem para a importação do acoplamento de uma classe (mensagens enviadas) quanto das mensagens que contribuem para a exportação do acoplamento (mensagens recebidas), representando a direção do acoplamento, constituem novas funcionalidades que foram adicionadas à XMIMetricTool. O cálculo se baseia na troca de mensagens entre as classes presentes nos diagramas de sequência, que demonstra o comportamento do software em determinados cenários ou funcionalidades. É importante ressaltar que uma classe pode aparecer em mais de um cenário, sendo necessário atingir uma boa abrangência nesta análise. Dessa forma, deve ser feita uma combinação de vários cenários, com o objetivo de apresentar valores que melhor demonstrem o que acontece no software, permitindo que pontos negativos possam ser discutidos e melhorados. A fim de se verificar efetivamente o acoplamento, neste trabalho leva-se em consideração a multiplicação da métrica CBO pelo total de mensagens enviadas e recebidas entre duas classes, contabilizando-se, dessa forma, o acoplamento nas duas direções.

3.2. A Ferramenta

A XMIMetricsTool se baseia na leitura de arquivos XMI contendo representação de modelo de classes e de diagramas de sequência para diferentes cenários de uso do software. O primeiro passo é o cálculo da métrica CBO para cada classe, realizando a contagem dos relacionamentos estáticos. O resultado é armazenado. Em seguida, realiza-se o cálculo do total de mensagens trocadas por cada classe, através da leitura de arquivo XMI contendo diversos diagramas de sequência para diferentes cenários de uso do sistema. O total deve ser calculado, através de escolha feita pelo usuário, de uma das

(5)

opções a seguir: a) levando em consideração somente as mensagens enviadas por cada classe; b) levando em consideração somente as mensagens recebidas por cada classe; c) levando em consideração as mensagens enviadas e recebidas por cada classe.

O resultado obtido é multiplicado pela CBO. Para apresentação do resultado do cálculo, o valor de referência do grau de normalidade é obtido através da média de valores do próprio modelo que está sendo avaliado, uma vez que não há valor de referência na literatura. Os resultados acima desse grau são destacados na cor vermelha.

3.3. Exemplo de Uso

Para exemplificar o uso da XMIMetricsTool, foi realizada a leitura de um arquivo XMI gerado pela ferramenta ArgoUML [ARGO 2009], de um sistema de restaurante, cujo diagrama de classes é apresentado na Figura 1.

Figura 1. Diagrama de classes de um sistema de um restaurante

As trocas de mensagens entre os objetos referentes às classes do exemplo apresentado são demonstradas através da Figura 2, que representa a troca de mensagens para o cenário ou funcionalidade de fechar uma conta no restaurante. A Figura 3 mostra a quantidade total de mensagens trocadas (enviadas + recebidas) por cada classe. Quanto maior o valor obtido, maior a responsabilidade que a classe exerce durante os cenários de execução do software.

A ferramenta realiza a contagem de mensagens levando em consideração os diversos cenários de execução do software, pois uma mesma classe pode aparecer em vários cenários. Para efeito de exemplo, foi considerado apenas um cenário. Maior atenção deve ser dada às classes que trocam mais mensagens, indicando, possivelmente, a necessidade de uma reestruturação no software. Percebe-se que a GUIConta está assumindo mais responsabilidades que o adequado, uma vez que não há no sistema um elemento controlador dos eventos de interface ou dos processos de negócio.

(6)

Figura 2. Diagrama de sequência do caso de uso “fechar conta”

Figura 3. Total de mensagens (enviadas + recebidas)

A Figura 4 mostra a combinação entre a métrica CBO e a quantidade total de mensagens trocadas (enviadas + recebidas) por cada classe. Se o resultado obtido é 0 (zero), significa que a classe não troca nenhuma mensagem ou ela não possui acoplamento estático, fazendo com que ele não interfira no cenário de execução do software. Percebe-se ainda que a classe Conta é central no sistema e que qualquer alteração nesta classe pode ter alto impacto.

(7)

Figura 4. Combinação da métrica CBO pelo total de mensagens

4. Trabalhos Relacionados

Nesta seção, ferramentas existentes no mercado são apresentadas, e suas características comparadas com a XMIMetricsTool através da Tabela 1. Dentre os itens considerados, estão: ferramenta livre (sem custo de utilização) e genérica (não está presa a um formato de arquivo de entrada ou acoplada a um ambiente de desenvolvimento).

Tabela 1. Comparação das Ferramentas para Cálculo de Métricas

Nome Livre Genérica Tipos de Métrica

Modelo Código Estática Dinâmica

SDMetrics(2009) Não Sim Sim Sim Sim Não

Objecteering (2009) Não Não Sim Não Sim Não

Together (BORLAND, 2009) Não Não Sim Sim Sim Não

JDepend(2009) Sim Não Sim Não Sim Não

EclipseMetric(SOURCEFORGE, 2009) Sim Não Sim Sim Sim Não JProfiler (EJ-TECHNOLOGIES, 2010) Não Não Não Sim Não Sim

XMIMetricsTool Sim Sim Sim Não Sim Sim

5. Conclusões e Trabalhos Futuros

As contribuições deste trabalho se encontram na integração de métricas estáticas e dinâmicas, verificadas em tempo de modelagem, permitindo a identificação precoce de possíveis erros no software, ou seja, no início do ciclo de vida, onde o custo de correção tende a ser menor. Essas métricas foram adicionadas à ferramenta XMIMetricsTool, conforme demonstrado em Barreto (2012).

A ferramenta apresenta algumas limitações, a saber: a) a análise dinâmica se baseia em diagramas de sequência desenvolvidos no projeto; b) não permite tratar os comandos condicionais e iterações nos diagramas de sequência; c) não permite o cálculo de acoplamento entre pares de classes; d) não permite o tratamento da herança na CBO.

(8)

Todas essas limitações representam trabalhos futuros, que devem levar à melhoria desta proposta. Um dos trabalhos futuros priorizados pelos autores é a captura de rastros de execução para cenários de uso do software, permitindo a obtenção das métricas sobre mensagens efetivamente trocadas pelos objetos em tempo de execução. Além disso, estudos de avaliação devem ser conduzidos a fim de comprovar a eficácia da abordagem em cenários reais de desenvolvimento e manutenção de software.

Referências

Arisholm, E. (2002) “Dynamic coupling measures for object-oriented software”, In: Eighth IEEE Symposium on Software Metrics, Lysaker, Norway, p. 1-10.

Argo (2009). Tigris. Disponível em: http://argouml.tigris.org. Acessado em 23/08/2011. Barcelos, M. e Silva, M. (2009) “Uma ferramenta de métricas de modelo para apoiar a

garantia da qualidade de software”. Monografia de Graduação – IFF/ Campos, RJ. Barreto, D. (2012) “Uma abordagem de integração de métricas estáticas e dinâmicas

para apoiar a avaliação da qualidade em modelos de software”. Monografia de Pós-Graduação – IFF/ Campos, RJ.

Chidamber, R. and Kemerer, F. (1994) “A metrics suite for object oriented design”, IEEE Transactions on Software Engineering, v. 20, n. 6, p. 476-493.

Eclipse Metrics (2012). Disponível em: www.sourceforge.net. Acessado em 02/05/2012.

Fenton, N. and Pfleeger, S. (1997) “Software Metrics: A Rigorous and Practical Approach”, Boston, PWS Publishing Company.

JDepend (2012). Disponível em: www.clarkware.com. Acessado em 02/05/2012. JProfiler (2012). Disponível em: www.ej-technologies.com. Acessado em 03/05/2012. Lorenz, M. and Kidd, J. (1994) “Object-Oriented Software Metrics”, Upper Saddle

River, New Jersey: Prentice Hall. 146p.

Objecteering (2012). Disponível em: www.objecteering.com. Acessado em 02/05/2012. Pressman, S. (2007) “Engenharia de software”, São Paulo: Pearson Makron Books. Rockenbach, R. (2003) “FWMetric: framework para métricas”. Universidade Federal de

Santa Catarina, Florianópolis.

SDMetrics (2012). Disponível em: www.sdmetrics.com. Acessado em 02/05/2012. Together (2012). Disponível em: www.borland.com. Acessado em 03/05/ 2012.

Vasconcelos, A. (2007) “Uma abordagem de apoio à criação de arquiteturas de referência de domínio baseada na análise de sistemas legados”, Tese de Doutorado, COPPE/UFRJ, RJ.

Vieira Neto, J. (2008) “Análise comparativa de ferramentas para métricas de software”, Passo Fundo, RS.

Yacoub, M. and Ammar, H. (1999); Robinson, T. “Dynamic metrics for object oriented designs”, Proc. of the Sixth International Symposium on Software Metrics, Metrics’99, Boca Raton, Florida USA, November 4-6 1999, pp.50-61.

Referências

Documentos relacionados

O primeiro passo para introduzir o MTT como procedimento para mudança do comportamento alimentar consiste no profissional psicoeducar o paciente a todo o processo,

forficata recém-colhidas foram tratadas com escarificação mecânica, imersão em ácido sulfúrico concentrado durante 5 e 10 minutos, sementes armazenadas na geladeira (3 ± 1

The main objectives of this data analysis are divided into two classes: i) General Statistics: give an overview of structured information on Wikipedia as a whole, showing raw numbers

Mineração de conhecimento interativa em níveis diferentes de abstração: Como é  difícil  prever  o  que  exatamente  pode  ser  descoberto  de  um  banco 

For additional support to design options the structural analysis of the Vila Fria bridge was carried out using a 3D structural numerical model using the finite element method by

O objetivo do curso foi oportunizar aos participantes, um contato direto com as plantas nativas do Cerrado para identificação de espécies com potencial

Em estudos mais aprofundados, tem-se a análise dinâmica não linear geométrica de estruturas laminadas modeladas com elementos tridimensionais de barra considerando o efeito

Este estudo tem como objetivos identificar os níveis de trauma manifestados e de estratégias de coping utilizadas pelos TEPH; caracterizar os incidentes mais