Métricas de Software – Determinação de Ponto por Função

Contextualização

É inconcebível que o projeto de um novo avião, um novo chip de computador ou um novo edifício comercial… seja conduzido sem a definição de medidas, sem determinar métricas para os vários aspectos de qualidade e sem usá-las como indicadores para orientar a maneira pela qual o projeto evoluirá.

E, além disso, o projeto de sistemas complexos baseados em software muitas vezes é realizado praticamente sem nenhuma medição.

A ironia disso tudo é que as métricas de projeto para software estão disponíveis, mas a grande maioria dos engenheiros de software continua ignorando sua existência.

As métricas de projeto para software de computador, como todas as outras métricas de software, não são perfeitas.

Continua o debate sobre sua eficácia e a maneira pela qual deveriam ser aplicadas.

Muitos especialistas argumentam que é necessária mais experimentação para que as medições de projeto possam ser usadas. E, além disso, projeto sem medição é uma alternativa inaceitável.

Examinaremos a seguir algumas das métricas de projeto mais comuns para software de computador. Cada uma delas pode proporcionar uma melhor visualização, e todas podem ajudar o projeto a evoluir para um nível maior de qualidade.

Fan-out e Fan-in

A hierarquia de controle, também chamada estrutura de programa, representa a organização dos módulos de programa.

Ela não representa aspectos procedimentais de software, tais como sequência dos processos, ocorrência/ordem das decisões ou repetição de operações.

A notação mais comum para representar a hierarquia é mostrada na figura.

Notamos que profundidade e largura constituem uma indicação do número de níveis de controle e do espaço de controle global, respectivamente.

Fan-out

É uma medida do número de módulos que são diretamente controlados por outro módulo, isto é, o número de subordinados imediatos para aquele módulo.

Fan-in

Indica quantos módulos controlam diretamente determinado módulo, isto é, o Fan-in de um módulo indica o número de superiores imediatos que ele possui.

O relacionamento de controle entre os módulos é expresso da seguinte maneira: um módulo que controla outro é superordenado a ele e, inversamente, que um módulo controlado por outro é subordinado ao controlador.

Na figura, o módulo X é superordenado aos módulos A, B, C. O módulo H é subordinado ao módulo E, que é subordinado ao módulo A.

Fan-out e Fan-in: características

A hierarquia de controle também representa duas características distintas: visibilidade e conectividade.

Visibilidade

Indica o conjunto de componentes de programas que pode ser invocado ou usado como dados por um determinado componente.

Por exemplo, um módulo de um sistema orientado a objeto pode ter acesso a uma ampla sucessão de objetos de dados que ele herdou, mas só faz uso de um pequeno número desses objetos de dados.

Conectividade

Indica o conjunto de componentes que é diretamente invocado ou usado como dados por determinado componente.

Por exemplo, um módulo que faça diretamente outro módulo iniciar a execução é conectado a ele.

Fan-out

• Deve-se ter no máximo 7 subordinados.

Fan-in

• Deve-se manter alto o número de superiores. Alto Fan-in é a recompensa pelo factoring inteligente e a remoção de módulos restritivos.

Ter uma função chamada por muitos superiores evita a necessidade de codificar a mesma função em vários lugares. Portanto, em tempo de manutenção, a duplicidade de alteração é eliminada.

Métricas de projeto da arquitetura

As métricas de projeto da arquitetura focalizam as características da arquitetura do programa com ênfase na estrutura arquitetônica e na eficácia dos módulos ou componentes dentro da arquitetura.

Essas métricas são uma “caixa-preta” no sentido de que elas não requerem qualquer conhecimento do funcionamento interno de um determinado componente de software.

Card e Glass [Car90] definem três medidas de complexidade de projeto de software:

Complexidade estrutural

Para arquiteturas hierárquicas (por exemplo, arquiteturas de chamada e retorno), a complexidade estrutural de um módulo i é definida da seguinte maneira:

Complexidade de dados

A complexidade dos dados (data complexity) proporciona uma indicação da complexidade na interface Interna para um módulo i e é definida como:

Em que v(i) é o número de variáveis de entrada e saída passadas para o do módulo i.

Complexidade de sistema

Por fim, a complexidade de sistema (system complexity) é definida como a soma da complexidade estrutural e de dados, especificada como:

ATENÇÃO: À medida que esses valores de complexidade aumentam, a complexidade global da arquitetura do sistema também aumenta.

Isso leva a uma maior probabilidade de que o trabalho de integração e teste também aumente.

Fenton [Fen91] sugere um conjunto de métricas de morfologia simples (isto é, forma) que permite que diferentes arquiteturas de programa sejam comparadas usando uma série de dimensões diretas. Referindo-se à arquitetura de chamada e retorno na Figura apresentada, podem ser definidas as seguintes métricas:

Tamanho = n + a

Para a arquitetura mostrada na Figura:

Tamanho = 19 + 24 = 43

Profundidade = caminho mais longo desde o nó raiz (topo) até o nó da folha. Logo, a profundidade = 5

Largura = número máximo de nós em qualquer nível da arquitetura.

Logo, largura = 7

A relação arco para nó,

r = a/n

mede a densidade de conectividade da arquitetura:

r= 24/19 = 1,26.

Indicadores de qualidade de software

A força aérea americana (U.S. Air Force Systems Command) desenvolveu um conjunto de indicadores de qualidade de software baseados nas características de projeto mensuráveis de um programa de computador. Usando conceitos similares àqueles propostos na norma IEEE Std. 982.1-1988, a Força Aérea usa informação obtida do projeto de dados e arquitetural para criar um índice de qualidade da estrutura do projeto (design structure quality index – DSQI) que varia de 0 a 1.

Os seguintes valores devem ser apurados para calcular o DSQI:

S1 – Número total de módulos definidos na arquitetura do programa.

S2 – Número de módulos cuja função correta depende da origem dos dados de entrada ou que produzem dados para serem usados em outro lugar (em geral, módulos de controle, entre outros, não seriam contados como parte de S2).

S3 – Número de módulos cuja função correta depende de processamento anterior.

S4 – Número de itens de base de dados (inclui objetos dados e iodos os atributos que definem objetos).

S5 – Número total de itens únicos de base de dados.

S6 – Número de segmentos de base de dados (diferentes registros ou objetos individuais).

S7 – Número de módulos com uma única entrada e saída (processamento de exceção não é considerado múltipla saída).

Uma vez determinados os valores S1 até S7, para um programa de computador podem ser calculados os seguintes valores intermediários:

Estrutura de programa

D1, que é definido da seguinte maneira:

Se o projeto da arquitetura foi desenvolvido por meio de um método distinto (por exemplo, projeto orientado a fluxo de dados (DFD) ou projeto orientado a objeto (OO), então D1 = 1, caso contrário D1 = 0.

Independência modular

D2 = 1 – (S2/S1)

Módulos não dependentes de processamento anterior

D3 = 1 – (S3/S1)

Tamanho da base de dados

D4 = 1 – (S5/S4)

Compartilhamento da base de dados

D5 = 1 – (S6/S4)

Característica de entrada/Saída do módulo

D6 = 1 – (S7/S1)

Cálculo do DSQI

Com os valores intermediários determinados, o DSQI é calculado da seguinte maneira:

DSQI = Σ wi/D

Em que i = 1 a 6, w1 é o peso relativo da importância de cada um dos valores intermediários e ΣW1 = 1 (se todos os Di tiverem o mesmo peso, então w1 = 0,167).

Métricas para projeto orientado a objeto

Há muita coisa sobre projeto orientado a objeto que é subjetivo – um projetista experiente “sabe” como caracterizar um sistema orientado a objeto de maneira que implemente efetivamente os requisitos do cliente.

Mas, à medida que um modelo de projeto orientado a objeto cresce em tamanho e complexidade, uma visão mais objetiva das características do projeto pode favorecer tanto o projetista experiente (que obtém uma visão adicional) quanto o novato (que obtém uma indicação da qualidade que de outra forma não estaria disponível).

Em um tratamento detalhado de métricas de software para sistemas orientados a objeto, Whitmire descreve nove características distintas e mensuráveis de um projeto orientado a objeto:

1. Tamanho. É definido em termos de quatro visualizações: população, volume, comprimento e funcionalidade. População é medida tomando-se uma contagem estática das entidades orientadas a objeto, como classes ou operações. Medidas de volume são idênticas às medidas de população, mas são coletadas dinamicamente – em determinado instante do tempo. Comprimento é a medida de uma cadeia de elementos de projeto interconectados (por exemplo, a extensão de uma árvore de herança é uma medida do comprimento). As métricas de funcionalidade proporcionam uma indicação indireta do valor fornecido ao cliente por uma aplicação orientada a objeto.
2. Complexidade. Assim como o tamanho, há muitas visões diferentes da complexidade do software. Whitmire vê a complexidade em termos de características estruturais examinando como as classes de um projeto orientado a objeto se inter-relacionam.
3. Acoplamento. As conexões físicas entre elementos do projeto orientado a objeto (por exemplo, o número de colaborações entre classes ou o número de mensagens passadas entre objetos) representam o acoplamento em um sistema orientado a objeto.
4. Suficiência. Whitmire define suficiência como “o grau com o qual uma abstração possui as características requeridas para ela, ou o grau com o qual um componente de projeto possui características em sua abstração, do ponto de vista da aplicação corrente”. Em outras palavras, perguntamos: “Que propriedades essa abstração (classe) precisa ter para ser útil para mim?”. Essencialmente, um componente de projeto (por exemplo, uma classe) é suficiente se refletir totalmente todas as propriedades do objeto de domínio da aplicação que está modelando – isto é, que a abstração (classe) possui as características necessárias para ele.
5. Totalidade. A única diferença entre totalidade e suficiência é “o conjunto de características em relação às quais comparamos a abstração ou o componente de projeto”. A suficiência compara a abstração do ponto de vista da aplicação corrente. A totalidade considera múltiplos pontos de vista, formulando a pergunta: “Que propriedades são necessárias para representar completamente o objeto de domínio do problema?”. Em virtude do critério da totalidade considerar diferentes pontos de vista, ele tem uma implicação indireta no grau com o qual a abstração ou o componente de projeto pode ser reutilizado.
6. Coesão. Assim como seu correspondente no software convencional, um componente orientado a objeto deverá ser projetado de maneira que tenha todas as operações funcionando em conjunto para atingir um objetivo único e bem definido. A coerência de uma classe é determinada examinando-se o grau segundo o qual “o conjunto de propriedades que ela possui faz parte do domínio do problema ou projeto”.
7. Originalidade. Uma característica similar à simplicidade, originalidade (aplicada tanto a operações quanto a classes) é o grau segundo o qual uma operação é atômica – isto é, a operação não pode ser construída por meio de uma sequência de outras operações contidas dentro de uma classe que apresenta um alto grau de originalidade e encapsula apenas operações primitivas.
8. Similaridade. O grau segundo o qual duas ou mais classes são similares em termos de sua estrutura, função, comportamento ou finalidade é indicado por essa medição.
9. Volatilidade. Conforme já afirmamos multas vezes neste livro, podem ocorrer alterações de projeto quando os requisitos são modificados ou quando acontecem modificações em outras partes de um aplicativo, resultando em adaptação obrigatória do componente de projeto em questão. A volatilidade de um componente orientado a objeto mede a possibilidade de que uma alteração venha a ocorrer.

Métricas orientadas a classe — o conjunto de métricas CK

O que é classe?

A classe é a unidade fundamental de um sistema orientado a objeto. Portanto, medidas e métricas para uma classe individual para a hierarquia da classe e colaborações entre classes serão valiosas quando tivermos de avaliar qualidade de projeto orientado a objeto.

Uma classe encapsula dados e a função manipula os dados. Com frequência é o “pai” das subclasses (às vezes chamadas de filhas) que herda seus atributos e operações. Muitas vezes elas colaboram com outras classes. Cada uma dessas características pode ser usada como base para a medida.

Chidamber e Kemerer propuseram um dos conjuntos mais amplamente conhecidos de métricas de software orientado a objeto. Também chamado de conjunto de métricas CK (CK metrics suite), os autores propuseram seis métricas de projeto baseado em classe para sistemas orientados a objeto. Vejamos uma delas:

Métodos ponderados por classe (weighted methods per class – WMC).

Suponha que n métodos de complexidade c1,c2 ,…, cn são definidos para uma classe C. A métrica especifica de complexidade escolhida (por exemplo, complexidade ciclomática) deverá ser normalizada de maneira que a complexidade nominal para um método assuma o valor 1,0.

WMC =  c1

Para i = 1 a n. O número de métodos e sua complexidade são indicadores razoáveis do trabalho necessário para implementar e testar uma classe.

ATENÇÃO:

Quanto maior for o número de métodos, mais complexa será a árvore de herança (todas as subclasses herdam os métodos de seus pais). Por fim, conforme o número de métodos cresce para uma dada classe, ela tende a se tornar cada vez mais específica de aplicação, limitando assim sua potencial reutilização. Por todas essas razões, o WMC deverá ser mantido o mais baixo possível.

Embora pudesse parecer relativamente fácil desenvolver uma contagem para o número de métodos em uma classe, o problema é na realidade mais complexo do que parece. Deverá ser desenvolvida uma abordagem consistente de contagem.

Referências

Base: Pós em Engenharia de Software – Estácio (EAD), com várias adaptações e melhorias.

PRESSMAN, Roger S. Engenharia de software. 7. ed. Mc Graw Hill, 2011.

SOMMERVILLE, Ian. Engenharia de software. 8. ed. Mc Graw Hill, 2007.

PADUA Filho, Wilson de. Engenharia de software: fundamentos, métodos e padrões. 3. ed. Rio de Janeiro: Editora LTC, 2009.

PETERS, James F. Engenharia de software. 3. ed. Campus, 2001.

VAZQUEZ, C.E. , SIMÕES,G.S., ALBERT, R.M. Análise de ponto de função medição, estimativa e gerenciamento de projetos de software. São Paulo: Editora Érica, 2009.

Exercícios de fixação

Lista -> http://josemalcher.net/lista-de-exercicios-de-metricas-de-software-lista-3/