Sobre a qualidade do software, Pressman (2005) diz que é uma mistura complexa de fatores que variam de acordo com a aplicação e com os clientes, sendo que há vários desses fatores de qualidade definidos.
Para avaliar a qualidade do produto software, Pressman (2005) afirma que há métricas que fornecem uma maneira quantitativa de avaliar a qualidade de atributos internos do produto, habilitando o engenheiro de software a avaliar a qualidade antes do produto ser construído. As métricas fornecem a visão aprofundada necessária para criar modelos efetivos de análise e projeto, código sólido, e testes rigorosos. Para que a métrica seja útil, deve ser independente da linguagem de programação e deve fornecer realimentação para o engenheiro de software.
Segundo o mesmo autor, há diversos tipos de métricas, de acordo com as fases no ciclo de vida do software. Métricas para o modelo de análise focalizam a funcionalidade, os dados e o comportamento. As métricas para projeto consideram aspectos da arquitetura, projeto em nível de componentes e projeto de interface. Métricas de projeto arquitetural consideram os aspectos estruturais do modelo de projeto. As métricas de projeto em nível de componentes fornecem indicação da qualidade do módulo. Métricas de projeto de interface fornecem indicação da adequação do leioute de uma GUI.
Para garantir a qualidade do software diversas métricas são criadas, como as de Chidamber e Kemerer (1994), para sistemas orientados a objetos. Os autores afirmam que o foco na melhoria do processo aumenta a demanda por medidas de software, ou métricas para gerenciamento do processo. Os autores propõem seis métricas, que são analiticamente avaliadas:
Métrica 1: Peso dos métodos por classe (Weighted Methods Per Class). O número de métodos e sua complexidade fornecem uma previsão do tempo de esforço requerido para desenvolver e manter a classe. Quanto maior o número de métodos de uma classe, maior é o impacto nas subclasses, desde que essas herdem todos os métodos definidos pela superclasse. Classes com grande número de métodos tendem a ser mais específicas, limitando a possibilidade de reuso.
Métrica 2: Profundidade da árvore de herança (Depth of Inheritance Tree). Quanto maior a profundidade de uma classe na hierarquia, maior o número de métodos a herdar, tornando-a mais complexa e seu comportamento mais imprevisível. Árvores profundas possuem maior complexidade de projeto, pois mais métodos e classes são envolvidos.
Capítulo 2 – Assuntos Abordados 19
Aprofundando uma classe em particular na hierarquia, é maior o potencial de reuso de métodos herdados.
Métrica 3: Número de filhos (Number of Children). Quanto maior o número de filhos, maior é o reuso, pois herança é uma forma de reutilização. Quanto maior o número de filhos, maior é a probabilidade de uma abstração imprópria da superclasse. Se uma classe tem um grande número de subclasses, essas podem estar sendo mal utilizadas. O número de subclasses dá idéia do potencial de influência que a classe tem no projeto. Se a classe tem um grande número de filhos, pode ser necessário mais testes nos métodos desta classe.
Métrica 4: Acoplamento entre classes de objetos (Coupling Between Object classes). Duas classes são acopladas quando métodos declarados em uma classe usam métodos ou instâncias de variáveis definidas por outra classe. Quanto mais independente uma classe é, mais fácil é o reuso em outra aplicação. Para aumentar a modularidade e promover o encapsulamento, deve haver pouco acoplamento de classes. Quanto maior o número de acoplamentos, maior a sensibilidade à mudanças em outras partes do projeto, e a manutenção é dificultada. Uma medida de acoplamento é necessária para determinar qual é a complexidade necessária nos testes de várias partes do sistema. Quanto maior o acoplamento, mais rigorosos devem ser os testes.
Métrica 5: Resposta para uma classe (Response For a Class). Se um grande número de métodos pode ser invocado em resposta a uma solicitação, o teste de uma classe se torna mais complicado, pois requer um alto nível de entendimento do testador. Quanto maior o número de métodos que pode ser invocado de uma classe, maior a sua complexidade. O valor do pior caso para as possíveis respostas reside na alocação apropriada do tempo de testes.
Métrica 6: Falta de coesão nos métodos (Lack of Cohesion Of Methods). A coesão de métodos de uma classe é desejável, desde que promova o encapsulamento. A falta de coesão de classes implica que classes devem ser divididas em duas ou mais subclasses. Baixa coesão implica em complexidade e aumento na probabilidade de erros durante o desenvolvimento.
Misra e Bhavsar (2003) apresentam um estudo que investiga a usabilidade de métricas no nível de projeto/código orientado a objetos como indicadores de dificuldade em manter o software. Desta forma, podem ser feitas considerações sobre projeto/código em fases iniciais do desenvolvimento, reduzindo dificuldade e aumentando a qualidade. Afirmam ainda que em um projeto de software em particular, para aumentar a qualidade do
produto final, o desenvolvedor pode diminuir algumas métricas de projeto e aumentar outras. Os autores chegam às seguintes conclusões:
• Quanto maior o número de classes, o número de métodos, o tamanho da classe ou do método, maior o nível de dificuldade.
• O aumento no número de linhas de código aumenta significativamente a dificuldade.
• A dificuldade do software é menor se há muitos métodos e atributos escondidos. Esconder métodos diminui mais a dificuldade do software do que esconder atributos.
• O aumento de polimorfismo aumenta a dificuldade do programa, pois permite ligações em tempo de execução.
• Aumento na herança de atributos, de métodos e no nível de profundidade das árvores aumenta a dificuldade e diminui a qualidade.
• Um aumento no controle de densidade, respostas para classes, e peso dos métodos aumenta a dificuldade. Desses, o aumento das respostas para classes é o que mais aumenta a dificuldade.
• Um aumento na média da profundidade dos caminhos aumenta a dificuldade, pois é mais difícil entender o software.
• O aumento no acoplamento ou falta de coesão aumentam a dificuldade, pois acoplamento reduz encapsulamento e aumenta a complexidade do software. A coesão dos métodos aumenta o encapsulamento e a qualidade.