domingo, 14 de junho de 2020

Métricas orientadas a classes: métricas CK – Chidamber e Kemerer

A classe é a unidade fundamental de um sistema OO e as métricas associadas a uma classe individual e às colaborações entre classes podem ajudar na avaliação da qualidade de um projeto OO. Chidamber e Kemerer propuseram um conjunto de métricas para sistemas OO, denominado CK metrics suite, que é bastante conhecido.

As 6 métricas CK, de acordo com Pressman e Maxim (2016, p. 667-669) são assim definidas:

  • WWC – Weighted Methods per Class (métodos ponderados por classe): suponha que são definidos para uma classe C n métodos de complexidade c1, c2...cn. A métrica específica de complexidade escolhida (como complexidade ciclomática, por exemplo) deve ser normalizada de forma que a complexidade nominal para cada método assuma o valor 1.0.
  • Podemos concluir que o WWC deve ser mantido o mais baixo possível, pois à medida que o número de métodos de uma classe cresce, ela tende a se tornar cada vez mais específica daquela aplicação, deixando seu potencial de reutilização muito baixo.
  • DIT – Depth of the Inheritance Tree (profundidade da árvore de herança): essa métrica se refere ao comprimento máximo do nó até a raiz da árvore de hierarquia de classes. Na medida em que DIT cresce, é possível que classes de nível inferior herdem muitos métodos. Portanto, um DIT baixo mostra-se mais desejável. Um DIT alto leva a uma maior complexidade do projeto, mas por outro lado, pode implicar que haja muitos métodos que possam ser reutilizados. Na árvore de hierarquia de classes da figura, o DIT é 3.
Diagrama de classes: exemplo de árvore de hierarquia de classes
Fonte: Pressman; Maxim (2016, p. 191).
  • NOC – Number of Children (número de filhas): as subclasses diretamente subordinadas a uma classe na hierarquia de classes são chamadas de filhas. Na figura 7 a classe Parede tem 3 subclasses SegmentoParede, Janela e Porta. Na medida em que o NOC aumenta, a quantidade de testes necessários para exercitar cada classe filha também aumenta.
  • CBO – Coupling Between Object classes (acoplamento entre objetos de classes): o modelo CRC pode ser usado para determinar o valor do CBO, que se refere ao número de colaborações para uma classe. Na medida em que o CBO aumenta, as modificações e os testes resultantes destas modificações tornam-se mais complexos e a reutilização da classe pode ser reduzida.
Exemplo de Cartão CRC
 
Fonte: Pressman; Maxim (2016, p. 192).
  • RFC - Response for a Class (resposta para uma classe): corresponde ao conjunto de métodos em potencial que podem ser executados em resposta a uma mensagem recebida por um objeto daquela classe. Na medida em que a RFC aumenta, tanto o trabalho de teste quanto a complexidade da classe também aumentam.
  • LCOM – Lack of Cohesion Methods (falta de coesão em métodos): cada método em uma classe pode acessar um ou mais atributos. LCOM corresponde ao número de métodos que acessam um ou mais atributos em comum. Se nenhum método acessa os mesmos atributos, LCOM = 0. Para exemplificar, considere uma classe com 6 métodos: 4 dos métodos têm um ou mais atributos em comum; portanto, LCOM =4. Para manter a coesão alta, é desejável se manter LCOM baixo.

Cartão CRC - Class-Responsibility-Collaborations

Embora não faça parte de UML, uma técnica chamada Cartões CRC é muito usada para atribuir responsabilidades durante o projeto OO.

CRC cards foram inventados por Ward Cunningham e Kent Beck. Cartão CRC é um cartão pequeno (para só escrever o essencial) para cada classe. Escreve-se o nome da classe, suas responsabilidades e colaborações. Só se pensa nas responsabilidades de alto nível. Os cartões são desenvolvidos em pequenos grupos em que cada pessoa assume o papel (Role) de uma ou mais classes.

Exemplo de Cartão CRC
Fonte: <dsc>.

sábado, 13 de junho de 2020

Baixo Acoplamento e Alta Coesão

Dentre estas características, as que mais se destacam são acoplamento e coesão. Uma boa aplicação OO deve seguir os princípios básicos de manter Baixo Acoplamento e Alta Coesão. Collares (2012) apresenta exemplos em Java que mostram soluções que corrigem erros para que estes princípios sejam mantidos:

“Elementos muito acoplados dependem muito uns dos outros, assim, se você altera um deverá alterar o outro.

Exemplo de Alto Acoplamento:

publicintgetIdade(){

    returnUtil.getFuncoes.getFuncoesData.calculaIdade(nascimento);

}

Correção para Baixo Acoplamento:

publicintgetIdade(){

    returnUtil.calculaIdade(nascimento);

}

Se uma classe faz mais do que ela deveria fazer, ela está com uma coesão baixa, e isso é ruim.

Exemplo de Baixa Coesão:

publicclass Aluno(){

    String nome;

    int[] notas;

        publicvoidsetNome(String nome){

            this.nome=nome;

}

        publicStringgetNome(){

            return nome;

}

        publicvoidsetNotas(int[] notas){

            this.notas=notas;

}

        publicdoublecalculaMedia(){

//código para calcular média

            return media;

}

}

Exemplo de Alta Coesão:

publicclass Aluno(){

    String nome;

        publicvoidsetNome(String nome){

            this.nome=nome;

}

        publicStringgetNome(){

            return nome;

}

}

        publicclass Notas{

    Aluno aluno;

    int[] notas;

        public Notas(Aluno aluno){

            this.aluno=aluno;

}

        publicvoidsetNotas(int[] notas){

            this.notas=notas;

}

        publicdoublecalculaMedia(){

//código para calcular média

            return media;

}

}

sexta-feira, 12 de junho de 2020

Métricas para projeto Orientado a Objetos-OO

Apesar de existirem muitas métricas que podem ser usadas como indicadores para orientar a forma pela qual um novo projeto deva evoluir, muitos engenheiros de software não as utilizam. Como veremos neste tópico, realizar um projeto sem medição é algo inaceitável!

Componentes de um projeto OO
 
Fonte: Bobicova Valeria/Shutterstock

De acordo com Pressman e Maxim (2016, p. 666), sistemas OO podem ser mensurados a partir das características:

  • Tamanho: contabiliza as entidades OO como classes ou métodos acoplados à profundidade de uma árvore de herança.
  • Complexidade: é definida pelas características estruturais do sistema OO, observando-se como as classes se inter-relacionam.
  • Acoplamento: contabiliza as conexões físicas entre elementos do sistema OO como número de mensagens passadas entre objetos.
  • Suficiência: responde a pergunta “que propriedades uma classe deve ter para ser útil?”, ou seja, se a classe possui as características dela requeridas.
  • Totalidade: está relacionada com a suficiência, pois determina se a classe entrega o conjunto de propriedades que reflete totalmente as necessidades do domínio do problema.
  • Coesão: é definida verificando se todos os métodos trabalham em conjunto para atingir uma finalidade única e bem definida.
  • Originalidade: reflete o grau segundo o qual um método é atômico. Um método não pode ser construído por meio de uma sequência de outros métodos dentro de uma classe.
  • Similaridade: reflete o grau em que duas ou mais classes são similares em relação à sua estrutura, função, comportamento ou finalidade.
  • Volatilidade: mede a probabilidade da ocorrência de uma modificação em um componente de um sistema OO.

quinta-feira, 11 de junho de 2020

Tipos de Métricas de Software

Métricas para qualidade de especificação

De acordo com Pressman e Maxim (2016, p. 663), há uma lista de características que podem ser usadas para avaliar a qualidade do modelo de requisitos e as especificações de requisitos correspondentes, como: não ambiguidade, totalidade, exatidão, compreensibilidade, consistência interna e externa, disponibilidade, rastreabilidade, modificabilidade, entre outras. Cada uma delas pode ser representada usando uma ou mais métricas.

Suponha que há Nr requisitos em uma especificação, entre os quais há Nf requisitos funcionais e Nnf requisitos não funcionais, tal que:

Nr = Nf + Nnf

Para se determinar a não ambiguidade dos requisitos, pode ser utilizada uma métrica com base na interpretação de cada requisito pelos revisores. Se Nii representa o número de requisitos para os quais todos os revisores tiveram a mesma interpretação (ii = interpretação idêntica), temos:

Q1 = Nii / Nr

Quanto mais próximo de 1 for Q1, menos ambiguidades haverá na especificação dos requisitos.

Considerando que Nfu representa o número de requisitos funcionais únicos, Ne representa o número de entradas definidas pela especificação e Ns o número de estados especificados, a métrica da totalidade dos requisitos funcionais Q2 pode ser obtida por:

Q2 = Nfu / (Ne x Ns)

Métrica Eficiência na Remoção de Defeitos ou Defect Removal Efficiency (DRE)

A métrica Eficiência na Remoção de Defeitos ou Defect Removal Efficiency (DRE), de acordo com Pressman e Maxim (2016, p. 718), “é uma medida da capacidade de filtragem das ações de garantia de qualidade e controle quando são aplicadas em todas as atividades da estruturas de processo”.

Sendo Ea= número de erros encontrados antes que o software seja entregue ao usuário final e Dd= número de defeitos encontrados depois que o software foi entregue ao usuário final, o DRE pode ser assim definido:

O valor ideal para DRE é 1, ou seja, nenhum defeito é encontrado no software. Mas de forma mais realista, Dd será maior que 0. À medida que Ea aumenta é provável que o valor final de Dd diminua (erros são removidos antes de se tornarem defeitos) e o valor global de DRE comece a se aproximar de 1.

Um dos objetivos desta métrica é incentivar a equipe de desenvolvedores a incorporar técnicas para que seja encontrado o maior número de erros possível antes da entrega do software.

Métricas orientadas a Casos de Uso ou Use Cases (UCs)

Os casos de uso ou Use Cases (UCs) são amplamente utilizados como método para descrever requisitos no nível dos clientes ou no domínio do negócio. De acordo com Pressman e Maxim (2016, p. 714), os UCs são definidos no início do processo de software, permitindo que sejam usados para estimativas antes de iniciar atividades de modelagem e construção.

O UC é independente da linguagem de programação e sua quantidade é diretamente proporcional ao tamanho do software em LOC e à quantidade de casos de teste que terão de ser projetados para exercitar o software.

quarta-feira, 10 de junho de 2020

Métricas orientadas a função - Pontos de Função (PF) ou FP (Function Points) - parte 3

[3] Passo 3: neste passo, utiliza-se uma expressão empírica proposta pelo modelo para obtenção dos pontos de função:

Apenas para ilustrar, vamos apresentar a tabela completamente preenchida, para um determinado projeto de software, o que seria feito no passo 1.

Supondo que no passo 2 foi realizado o cálculo que resultou em

o valor que indica que o produto é moderadamente complexo.

No passo 3 calculamos o PF.

PF = 50 x [0.65+ (0.01 x 46)] = 55.5 => 56

terça-feira, 9 de junho de 2020

Métricas orientadas a função - Pontos de Função (PF) ou FP (Function Points) - parte 2

[2] Passo 2: para o cálculo dos pontos de função, você terá que avaliar as 14 questões apresentadas no quadro 1, também relacionadas às funcionalidades do software a ser desenvolvido. Para cada uma dessas perguntas, você terá que atribuir um fator de ajuste de valor ou Value Adjustment Factor – VAF, Fi (i = 1 a 14), obedecendo à escala proposta pelo modelo apresentado no quadro 2.

Quadro 1 – 14 perguntas relacionadas às funcionalidades
1. O sistema exige backup e recuperação confiáveis 8. Os arquivos são atualizados on-line?
2. É requerida comunicação de dados? 9. Entradas, saídas, arquivos e consultas são complexos?
3. Existem funções de processamento distribuído? 10. O processamento interno é complexo?
4. O desempenho é crítico? 11. O código é projetado para ser reusável?
5. O sistema funcionará num sistema operacional existente e intensamente utilizado? 12. A conversão e a instalação estão incluídas no projeto?
6. São requeridas entrada de dados on-line? 13. O sistema é projetado para múltiplas instalações em diferentes organizações?
7. As entradas on-line requerem que as transações de entrada sejam construídas com várias telas e operações? 14. A aplicação é projetada de forma a facilitar mudanças e o uso pelo usuário?
Fonte: baseado em Pressman; Maxim (2016, p. 661).

Quadro 2 – Escala de VAFs – Value Adjustment Factors
Fonte: baseado em Pressman; Maxim (2016, p. 661).

Para evitar o problema da subjetividade ao avaliar a influência de cada funcionalidade, o IFPUG desenvolveu recomendações a serem seguidas.

No final desse segundo passo, você terá a soma das influências de cada uma das 14 perguntas. O valor dessa soma variará de um mínimo de 0 (todas as 14 perguntas tendo valor 0) a um valor máximo de 70 (todas as perguntas tendo valor igual a 5).

segunda-feira, 8 de junho de 2020

Métricas orientadas a função - Pontos de Função (PF) ou FP (Function Points)

A métrica Ponto de Função (PF) ou Function Point (FP) pode ser utilizada como forma de medir a funcionalidade fornecida por um sistema. Pressman e Maxim (2016, p. 659) indicam que podem ser usadas para:

  • estimar o custo ou trabalho necessário para projetar, codificar e testar o software;
  • prever o número de erros que serão encontrados durantes os testes; e
  • prever o número de componentes e/ou o número de linhas de código-fonte projetadas.

Os PFs são derivados de medidas calculáveis do domínio de informações do software com base em:

  1. ExternalInputs-EIs (número de entradas externas): cada entrada externa tem origem em um usuário ou é transmitida de outra aplicação. Fornece dados distintos orientados à aplicação ou informações de controle.
  2. External Outputs-EOs (número de saídas externas): cada saída externa é formada por dados derivados da aplicação e fornece informações para o usuário.
  3. ExternalinQuiries-EQs (número de consultas externas): refere-se a uma entrada online que resulta na geração de alguma resposta imediata do software na forma de uma saída online.
  4. InternalLogical Files-ILFs (número de arquivos lógicos internos): cada arquivo lógico interno é um conjunto de dados que fica dentro dos limites da aplicação e é mantido por meio de entradas externas.
  5. External Interface Files-EIFs (número de arquivos de interface externos): cada arquivo de interface externo é um conjunto de dados que fica fora da aplicação, mas fornece dados que podem ser usados pela aplicação.

Para o cálculo de Pontos de Função, os passos descritos a seguir devem ser seguidos.

[1] Primeiro passo: preencher as colunas sombreadas da tabela. Note que nessa tabela você deve preencher apenas os dados da coluna Contagem e fazer o cálculo da coluna Contagem x Fator de Peso e totalizar a Contagem Total. As colunas Valor do domínio da informação e Fator de Pesos já estão preenchidas, pois são valores são propostos pelo modelo e, a princípio, são fixos. Então, nesse passo, você terá que estimar a quantidade de cada parâmetro previsto para o software a ser desenvolvido e atribuir um fator de peso para cada um deles.

Uma grande questão que surge é como minimizar a subjetividade na atribuição desses fatores de ponderação, porque isso pode variar de pessoa para pessoa. O IFPUG – International Function Points Users Group – disponibiliza uma série de recomendações visando minimizar essa subjetividade.

Uma vez preenchida a tabela, você terá o valor de Contagem Total, o qual será utilizado no terceiro passo do cálculo.

Tabela para Pontos de Função
Valor do domínio da informação Contagem Fator de Peso Contagem x Fator de Peso
Simples Médio Complexo
Nº de Entradas Externas (EIs)   3 4 6  
Nº de Saídas Externas (EOs)   4 5 7  
Nº de Consultas Externas (EQs)   3 4 6  
Nº de ArqLóg Internos (ILFs)   7 10 15  
Nº de ArqInterf Externos (EIFs)   5 7 10  
Contagem Total  
Fonte: baseada em Pressman; Maxim (2016, p. 660).