monitoramento de métricas de código-fonte - stoa...

1

Monitoramento de Métricas de Código-Fonte:

uma abordagem a ser explorada pelo Governo na verificação da qualidade dos

produtos de software

Paulo Meirelles(FGA/UnB – CCSL/USP)

[email protected] Paulo Meirelles is licensed under a Creative Commons Atribuição 2.5 Brasil License

http://creativecommons.org/licenses/by/2.5/br/

2

Introdução (1)

3

Bjarne StroustrupInventor of C++

O que é código limpo?

“ I like my code to be elegant and efficient. The logic should be straighforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well. ”

4

Grady BoochAuthor of Object Oriented Analysis and

Design with Applications


“ Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer's intent but rather is full of crisp [clearly defined] abstractions and straighforward lines of control.”

5

Dave ThomasFounder of OTI, godfather of

the Eclipse Strategy


“ Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API. Code should be literate since depending on the language, not all necessary information can be expressed clearly in code alone.”

6

Michael FeathersAuthor of Working Effectively

With Legacy Code


“ I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code's author, and if you try to imagine improvements, you're led back to where you are, sitting in appreciation of the code someone left for you – code left by someone who cares deeply about the craft.”

7

Ron JeffriesAuthor of Extreme

Programming Installed


“ In recent years I begin, and nearly end, with Beck's rules of simple code. In priority order, simple code:

● Runs all tests

● Contains no duplication

● Expresses all the design ideas that are in the system

● Minimizes the number of entities such as classes, methods, functions, and the like.”

8

Ward CunninghamInventor of Wiki, Fit and much more

”Godfather of all those who care about code”


You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the codes also makes it look like the language was made for the problem.”

9

Simple

Straightforward

Efficient

Expressive

Runs all tests

Literal

Turns out to be what you expected

Minimal

Contains no duplications

Full of meaning

Without obvious improvements

Written by someone who

cares

Reads well

Beautiful: when the language was made for the problem


10

???

caminhoR(Vertice v):Vertice west[v] = 0for(w = 0; w < tamanho(); w++) if(adj(v,w))if(est[w] == 1):imprime(w)caminhoR(w)

11

Melhor assim?

16

Métricas de Código-Fonte

Métricas usadas no contexto de sistemas de software orientados a objeto

18

Linhas de Código (LOC)

É a medida mais comum para o tamanhode um software. São contadas apenas as linhas executáveis, ou seja, são excluídas

linhas em branco e comentários ...

19


No exemplo, a classe HelloWorld tem LOC=3,contando as linhas 1, 3 e 4. A linha 4, apesar de possuir 2 instruções, conta como apenas 1

linha ...

20


Para efetuar comparações entre sistemas usando LOC, é necessário que ambos

tenham sido feitos na mesma linguagem de programação e que o estilo

esteja normalizado …

21


Os intervalos sugeridos para o LOC de uma classe são: até 70 (bom); entre 70 e 130

(regular); de 130 em diante (ruim).

23

AMLOCNúmero médio de linhas por

método

Indica se o código está bem distribuído entre os métodos. Quanto maior, mais pesados são os métodos. É preferível ter muitas operações pequenas e de fácil entendimento que poucas

operações grandes e complexas ...

24

AMLOCNúmero médio de linhas por

método

No exemplo, a classe Printer tem AMLOC=3, pois possui 2 métodos e LOC= 6. Os

intervalos sugeridos são: até 10 (bom); entre 10 e 13 (regular); de 13 em diante (ruim).

25

DITProfundidade da árvore de

herança

É o número de superclasses e/ou classes ancestrais da classe sendo analisada. São

contadas apenas as superclasses do sistema, ou seja, as classes de bibliotecas não são

contabilizadas. No exemplo, a classe HelloWorldPrinter tem DIT = 1 e nas demais

DIT = 0 ...

26

DITProfundidade da árvore de

herança

Quanto maior for o valor DIT, maior é o número de atributos e métodos herdados, e

portanto maior é a complexidade. Os intervalos sugeridos são: até 2 (bom); entre 2

e 4 (regular); de 4 em diante (ruim).

28

NPANúmero de atributos públicos

Os atributos de uma classe devem servir apenas às funcionalidades da própria classe.

Portanto, as variáveis/atributos de classe devem ser ocultadas para evitar

complexidade, pois fica difícil prever os efeitos colaterais de alterar atributos

públicos ...

29

NPANúmero de atributos públicos

NPA mede o encapsulamento. O valor ideal dessa métrica é zero. Os intervalos sugeridos

são: até 1 (bom); entre 1 e 9 (regular); de 9 em diante (ruim).

30

NPMNúmero de métodos públicos

Representa o tamanho da interface da classe. Os métodos públicos representam os

serviços que a classe disponibiliza ...

31

NPMNúmero de métodos públicos

Valores altos para essa métrica indicam que a classe tem demasiadas funcionalidades e

que poderia ser quebrada. Os intervalos sugeridos são: até 10 (bom); entre 10 e 40

(regular); de 40 em diante (ruim).

32

NPNúmero de Parâmetros

Calcula o número de parâmetros de um método. Obtemos valor zero quando o método avaliado não possui parâmetro. Muitos parâmetros de um método pode indicar que ele está com mais de uma

responsabilidade ...

33

LCOM4Ausência de coesão em métodos

Seja M = {M1, …, Mn} o conjunto dos métodos da classe analisada. Dois métodos

Mi e Mj estão relacionados se ambos acessam pelo menos um mesmo atributo da classe, ou se Mi chama ou é chamado por

Mj . LCOM4 é a quantidade de partições de “M” formadas após separar os métodos em

conjuntos de métodos relacionados ...

34


No exemplo, a classe Printer tem LCOM4 = 1, pois todos os métodos acessam a variável

message. HelloWorldPrinter tem LCOM4 = 2, pois o contrutor e o método doNothing() não

estão relacionados ...

35


Se uma classe tem diferentes conjuntos de métodos não relacionados entre si, é um

indício de que a classe deveria ser quebrada em classes menores e mais coesas.

Os intervalos sugeridos são: até 2 (bom); entre 2 e 5 (regular); de 5 em diante (ruim).

38

CBOAcoplamento (ligações, conexões)

entre Objetos (classes)

Mede o acoplamento (conectividade) de uma classe. Se uma classe C1 acessa um método ou atributo da classe C2, dizemos que C1 é

cliente da classe fornecedora C2...

39



● n = número total de classes

40



No nosso exemplo, CBO(Printer) é 2, pois ela é utilizada pelas outras duas classes.

HelloWorldPrinter é filha e portanto cliente de Printer ...

41



Se o valor dessa métrica for grande, uma mudança na classe tem potencialmente mais

efeitos colaterais, tornando mais difícil a manutenção. Os intervalos sugeridos são: até

2 (bom); entre 2 e 20 (regular); de 20 em diante (ruim).

43

ACCM (McCabe)Complexidade Ciclomática

Calcula o número de caminhos linearmente independentes no método analisado,

conhecido como complexidade ciclomática ...

44


Obtemos 1 quando não há quebra do fluxo principal. Cada estrutura de controle de fluxo presente no corpo do método adiciona 1 no

valor total da CYCLO ...

45


Quando os valores de MaxNesting e CYCLO são próximos, sabemos que muitos dos

controladores de fluxo presentes no método estão encadeados em uma mesma estrutura.

Quando são muito distantes, podemos concluir que os controladores estão

espalhados em estruturas diferentes e que elas não são muito profundas.

52

Introdução (2)

53

Software livre● Influenciando a indústria de software e a

economia global nas últimas décadas [Benkler, 2006]

● É considerado um método ágil de desenvolvimento de software [Fowler, 2000; Abrahamsson, 2002; Warsta e Abrahamsson, 2003; Corbucci, 2011]

54

Software livre

● Pessoas, empresas e governos ainda relutantes na adoção (QualiPSO)

● Incertezas legais, comerciais, questões culturais, falta de confiança no produto e no suporte (QualiPSO)

55

Qualidade do produto?● Funcionalidade● Confiança● Usabilidade● Eficiência● Manutenibilidade● Portabilidade

[ISO/IEC9126-1, 2001]

56

Qualidade do produto?

● Funcionalidade● Confiança● Usabilidade● Eficiência● Manutenibilidade● Portabilidade

57

Por que código-fonte?

A codificação passou a também ser reconhecida como um trabalho

intelectual e criativo.

58

Por que código-fonte?

A maior parte dos esforços são direcionados à qualidade do código

desenvolvido.

59

Tese de doutorado na USP

Definir como monitorar e avaliar a qualidade de projetos de software livre, através do estudo das suas

métricas, obtidas pela análise semi-automática de seu código-fonte.

60

Questões de Pesquisa

QP: Quais métricas devem ser “controladas” (monitoradas) ao longo do tempo?

61

Questões de Pesquisa

QP: As métricas de código-fonte “melhoram” com o amadurecimento dos projetos?

62

Metodologia

● Mineração de repositórios de código-fonte de projetos de software livre

● 5 estudos empíricos● Análise quantitativa

63

Resultados● Uma abordagem para a observação das

métricas de código-fonte● Identificação das distribuições

estatísticas dos valores de métricas e os seus valores frequentes

● uma extensão do modelo de causalidade do conceito de atratividade de projetos de software livre

64

Resultados

● Ferramenta de coleta de métricas de código-fonte

● Web service para interpretação de métricas de código-fonte

● Rede de monitoramento de métricas de código-fonte

65

Conteúdo

● Desenvolvimento de software livre● Métricas de Código-Fonte● Estudos● Ferramentas● Conclusão

66

Conteúdo


[Kon et al., 2011]

Interação entre desenvolvedores

Níveis de participação

[Crowston e Howison, 2005]

69

Conteúdo


70

Tamanho(LOC)

71

Coesão(LCOM4)

72

Acoplamento(CBO)

73

Conteúdo


Contradição entre os trabalhos relacionados:

1) Normal ou Leis de Potência?

2) A média dos valores das métricas é um valor informativo para os estudos?

Distribuição e valores frequentes das

métricas em projetos de software livre

76

Hipóteses

H1: O tipo da distribuição dos valores das métricas de código-fonte tendem a ser diferentes entre projetos diferentes.

77

Hipóteses

H2: A média e mediana não são dados informativos na maioria dos casos.

78

Hipóteses

H3: Ao agrupar os projetos por linguagem de programação, será possível observar valores frequentes das métricas nos projetos avaliados.

79

Coleta dos Dados

● Ohloh.net● API● Scripts● Projetos com mais contribuidores e

usuários (ranking)● Fontes dos repositórios oficiais

80

Metodologia

● Análise descritiva● Testes das distribuições

● Weibull, Poisson, Gamma, Exponencial e Pareto

● Critério de Akaike (FitDist no R)

● Verificação dos percentis (e quantis)

81

Projetos

82

Projetos

83

Média da Complexidade Ciclomática por método

84

Média da Complexidade Ciclomática por método

85

Ausência de coesão em métodos

86

Ausência de coesão em métodos

87

Número de linhas de código

88

Número de linhas de código

89

Complexidade estrutural

90

Complexidade estrutural

Correlação entre as métricas

92

Linux

93

Free BSD

94

Eclipse

95

Open JDK 8

96

Chrome

97

Firefox

98

Evolução Firefox

99

Resultados (VLC)

100

Resultados (MPlayer)

101

Resultados (Kalibro)

102

Resultados (Kalibro-Tests)

103

Conteúdo


MezuroRede de monitoramento de

código-fonte

106

Monitorando um projeto

113

Criando uma configuração para monitoramento

122

Visualizaçãode Software

123

Escalabilidadede web services

124

Mineração de dados

125

Ferramentas/coletores

126

Conteúdo


127

Conclusão● Quais métricas devem ser “controladas”

(monitoradas) ao longo do tempo?● Dependerá de quais característica do código

está interessado em monitorar, por isso nossa abordagem sugere que o monitoramento seja “configurável”. Observando a correlação, uma sugestão é: ACC, ACCM, ANPM, DIT, AMLOC, NOM, NPA, SC.

128

Conclusão

Os valores das métricas de código-fonte seguem distribuições não-triviais, assim olhar

como medi-las se faz necessário.

129

Contribuições● Uma abordagem para a observação das

metricas de código-fonte● Identificação das distribuições

estatísticas dos valores de métricas e os seus valores frequentes

● uma extensão do modelo de causalidade do conceito de atratividade de projetos de software livre

130

Contribuições

● Ferramenta de coleta de métricas de código-fonte

● Web service para interpretação de métricas de código-fonte

● Rede de monitoramento de métricas de código-fonte

131

Contribuições

● Implicações gerenciais práticas● Empresas● Governos

– Relatório técnico para o TCU

132

Monitoramento de Métricas de Código-Fonte:

uma abordagem a ser explorada pelo Governo na verificação da qualidade dos

produtos de software

Paulo Meirelles(FGA/UnB – CCSL/USP)

[email protected] Paulo Meirelles is licensed under a Creative Commons Atribuição 2.5 Brasil License

http://creativecommons.org/licenses/by/2.5/br/

monitoramento de métricas de código-fonte - stoa...

Documents