TCC

CURSO SUPERIOR DE TECNOLOGIA EM ANLISE E
DESENVOLVIMENTO DE SISTEMAS
LUCAS NOGUEIRA PADRO
TESTES DE QUALIDADE DE CDIGO COM A FERRAMENTA SONAR
Campos dos Goytacazes/RJ
2013
CURSO SUPERIOR DE TECNOLOGIA EM ANLISE E
DESENVOLVIMENTO DE SISTEMAS
Trabalho de concluso de curso apresentado
ao Instituto Federal Fluminense como parte
dos requisitos para para concluso do Curso
Superior de Tecnologia em Anlise e Desen-
volvimento de Sistemas.
Orientador: Prof. Maria Alcilia Alves Rocha
Campos dos Goytacazes/RJ
2013
Trabalho de concluso de curso apresentado ao
Instituto Federal Fluminense como requisito
obrigatrio para obteno de grau em Tecnolo-
gia em Anlise e Desenvolvimento de Sistemas.
Aprovado em 30 de abril de 2013
Banca avaliadora:
Prof. MariaAlcilia Rocha (Orientadora)
Msc
Instituto Federal de Educao, Cincia e Tecnologia Fluminense / Campus Campos
Centro / UENF
Prof. Fulano
ttulo
Centro
Prof. Beltrano
ttulo
Centro
Dedico este trabalho ao meu companheiro, alhado e irmo mais novo, Arthur.
AGRADECIMENTOS
Maria Alcilia Rocha pela prontido.
Estamos, portanto, de acordo em que as
palavras so signos.
Santo Agostinho
RESUMO
Este trabalho mostra a utilizao da ferramenta Sonar em testes de qualidade de cdigo Python.
PALAVRAS-CHAVE: Testes de qualidade, Software livre, Sonar, Python
ABSTRACT
This work shows how to use Sonar tool in order to test quality Python codes.
KEYWORDS: Quality tests, Free software ,Python, Sonar
LISTA DE FIGURAS
2.1 Variveis em Python. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Tela inicial do Sonar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Anlise oferecida pelo Sonar. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Violations Drilldown. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1 O Ciclo de Vida do Software. Fonte: Wikipedia(2013) . . . . . . . . . . . . . 27
4.1 Sada do Doxygen. Fonte: Flip Code (2012) . . . . . . . . . . . . . . . . . . . 35
5.1 Modelo de teste em Caixa-preta. . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Modelo de teste em Caixa-branca. . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3 Modelo de Teste de Integrao Top-down. . . . . . . . . . . . . . . . . . . . . 46
5.4 Modelo de Teste de Integrao Bottom-up. . . . . . . . . . . . . . . . . . . . . 46
6.1 Tela inicial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2 Relatrio da anlise de Alunos.py. . . . . . . . . . . . . . . . . . . . . . . . . 53
6.3 Time Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.4 Reviews. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.5 Hotspots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.1 Tela de Login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.2 Adicionar Material de Consumo. . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.3 Adicionar Material Permanente. . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.4 Adicionar empenho. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.5 Adicionar Chave. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.6 Adicionar Publicao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.7 Adicionar Motorista Temporrio. . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.8 Adicionar Viatura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.9 Adicionar Contrato. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.10 Tela Principal do Ponto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.11 Tela de Frequncia do Ponto. . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.12 Adicionar Baixa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.13 Modicar processo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.14 Usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.15 Adicionar curso ou concurso. . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
8.1 Lista de projetos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
8.2 Mdulos analisados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.3 Anlise detalhada do mdulo django_evolution. . . . . . . . . . . . . . . . . . 65
8.4 Anlise detalhada do mdulo django_evolution. . . . . . . . . . . . . . . . . . 66
8.5 Drilldown: solues para os problemas. . . . . . . . . . . . . . . . . . . . . . 66
8.6 Violaes no mdulo conexaoBD. . . . . . . . . . . . . . . . . . . . . . . . . 67
8.7 Anlise detalhada do arquivo dumscript.py. . . . . . . . . . . . . . . . . . . . 68
SUMRIO
1 INTRODUO 13
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Justicativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 TECNOLOGIAS EMPREGADAS 15
2.1 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Variveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.2 Atribuio de Varivel . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.3 Strings em Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.4 Listas e Dicionrios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.5 Classes e Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Sonar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 ENGENHARIA DE SOFTWARE 23
3.1 Denio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Histrico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1 Software de Primeira Gerao . . . . . . . . . . . . . . . . . . . . . . 25
3.2.2 Software de Segunda Gerao . . . . . . . . . . . . . . . . . . . . . . 25
3.2.3 Software de Terceira Gerao . . . . . . . . . . . . . . . . . . . . . . 26
3.2.4 Software de Quarta Gerao . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.5 Software de Quinta Gerao . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Ciclo de Vida do Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 Qualidade do Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4 QUALIDADE DE SOFTWARE 29
4.1 Denies de Qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Padres de Qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Qualidade do cdigo-fonte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4 Mecanismos para melhoria de cdigo-fonte . . . . . . . . . . . . . . . . . . . 34
4.4.1 Documentao do cdigo . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.2 Refatorao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.3 Padronizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.4 Anlise de Complexidade . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.5 Programao Defensiva . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.6 Testes de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5 TESTES DE SOFTWARE 39
5.1 Defeitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.1 Identicao de Defeitos . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2 Testes de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.1 Planejamento de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3 Casos de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.1 Fatores Psquicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.2 Coberturas de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.4 Tipos de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.4.1 Caixa-preta e Caixa-branca . . . . . . . . . . . . . . . . . . . . . . . . 44
5.4.2 Teste de Estresse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.4.3 Testes de Integrao . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.4.4 Teste Orientado a Objetos . . . . . . . . . . . . . . . . . . . . . . . . 47
5.4.5 Teste de Validao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.4.6 Test-driven Develpment . . . . . . . . . . . . . . . . . . . . . . . . . 48
6 TESTES COM O SONAR 50
6.1 O Sonar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.1.1 Instalando o Sonar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.1.2 Instalando plugin para Python . . . . . . . . . . . . . . . . . . . . . . 51
6.2 Testes com o Sonar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.3 Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7 O SUAP 55
7.1 SUAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.2 Django . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.3 Conhecendo o SUAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.3.1 Almoxarifado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.3.2 Chaves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.3.3 Frota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.3.4 Contratos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.3.5 Terminal de Ponto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.3.6 Patrimnio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.3.7 Protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.3.8 Recursos Humanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.3.9 Telas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8 ESTUDO DE CASO 64
8.1 Anlise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
9 CONCLUSES 69
9.1 Objetivos alcanados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
REFERNCIAS BIBLIOGRFICAS 70
1 INTRODUO
Nos primrdios da Informtica, todos os sistemas eram programados para um deter-
minado equipamento. Obviamente tratavam-se de sistemas muito menos complexos que os
sistemas atuais. Porm com o aumento da complexidade dos Sistemas de Informtica, cada vez
mais os meios de projeto e reparo se tornavam complicados. Isso signicou o aparecimento de
meios de garantir a qualidade de tais complexos projetos, ocasionando por m uma necessidade
do teste de software (PRESSMAN, 2010).
Inicialmente o teste de software era feito manualmente por um programador especia-
lista em testes. Posteriormente comeou-se a utilizar testes automatizados, isto , softwares
construdos para testar outros softwares (PRESSMAN, 2010).
Este trabalho visa discutir tcnicas que dizem respeito Engenharia de Software. Mais
especicamente sobre a utilizao de testes visando a qualidade de software, que um setor da
Engenharia de Software.
1.1 Objetivos
Este trabalho pretende contribuir com a divulgao da ferramenta Sonar.
Alm disso, visa estabelecer os meios pelos quais a qualidade de software pode ser
implementada.
Sendo assim o trabalho apresenta as caractersticas das principais tecnologias envolvidas
no desenvolvimento e atuao do mesmo, bem como sua estrutura atravs dessas.
Tambm foi possvel oferecer uma melhoria de qualidade de um sistema administrativo.
1.2 Justicativa
Optou-se por divulgar a ferramenta Sonar que gratuita e oferece diversos recursos
sosticados para anlise de qualidade.
14
1.3 Metodologia
Escrever o passo-a-passo seguido para desenvolver o trabalho desta monograa.
Este trabalho se divide em oito captulos, sendo este primeiro um captulo introdutrio
e explicativo sobre o contedo do trabalho e de suas intenes.
O segundo captulo deste trabalho mostra brevemente a sintaxe da linguagem de progra-
mao Python e dene do que se trata a ferramenta de testes de qualidade Sonar.
J no terceiro captulo caram demonstrados os principais conceitos de engenharia de
software, bem como sua denio e histrico.
Ao quarto captulo possvel encontrar as informaes centrais deste trabalho, qualidade
de software. So conceituadas as principais ideias sobre qualidade de software, tcnicas e
padres de qualidade, bem como casos de omisso de qualidade.
O quinto captulo aborda a questo do teste de software, que um dos meios de se
assegurar a qualidade de software. L so designados diversos caminhos e tipos de testes, alm
de discriminao dos defeitos.
As informaes necessrias para se instalar e manipular o Sonar so encontradas no
sexto captulo.
OSUAP descrito no stimo captulo. Suas principais funcionalidades so mencionadas
e algumas das suas principais telas so mostradas.
O oitavo captulo faz um estudo do caso em que o SUAP submetido anlise do Sonar.
Foram encontradas violaes de qualidade e sugeridas algumas correes.
Por m no nono captulo so mencionadas as concluses e contribuies deste trabalho.
2 TECNOLOGIAS EMPREGADAS
Basicamente duas tecnologias foram utilizadas nesse trabalho, a linguagem de progra-
mao Python e a ferramenta de testes Sonar.
2.1 Python
Python a representante de uma revoluo nas linguagens de programao. Pretende
servir como arcabouo para os mtodos geis de desenvolvimento, que preconizam um cdigo
limpo e fcil de ser entendido. Por isso que Python, como outras linguagens, tenta se despir
de tudo que parece supruo as linguagens tradicionais. Vejamos um exemplo de cdigo Java
simples.
1 i n t v a r i a v e l _ a , v a r i a v e l _ b ;
2
3 i n t soma ( v a r i a v e l _ a , v a r i a v e l _ b )
4 {
5 r e t u r n v a r i a v e l _ a + v a r i a v e l _ b ;
6 }
Cdigo 2.1: Exemplo de funo em Java.
O mesmo cdigo em Python poderia ser escrito da seguinte maneira:
1
2 def soma ( v a r i a v e l _ a , v a r i a v e l _ b ) :
3 r e t u r n v a r i a v e l _ a + v a r i a v e l _ b ;
Cdigo 2.2: Exemplo de funo em Python.
Apesar de simples, o cdigo Python acima nos ensina trs coisas. No h necessidade
de declarao do tipo das variveis, no se utiliza ";"para nalizar as linhas e nem "}"para de-
monstrar o incio e nal da funo. Isso torna o cdigo Python bastante semelhante a linguagem
natural humana, facilitando seu entendimento at mesmo por principiantes em programao e
sobretudo diminuindo drasticamente a quantidade de linhas no cdigo.
16
Uma outra interessante caracterstica do cdigo em Python, que todo recurso consi-
derado objeto para o compilador, desde variveis at funes.
2.1.1 Variveis
Como armado anteriormente, o cdigo em Python carece de declarao de variveis.
Isso porque tanto a varivel quanto o valor atribudo a ela so objetos dentro do compilador.
Objetos estes que so associados atravs da atribuio da varivel e no da declarao, que
propriamente no h em Python.
Nativamente, Python tambm oferece suporte a nmeros complexos:
1
2 numero_compl exo = 3 + 4 j
Cdigo 2.3: Exemplo de uso de nmero complexo em Python.
A seguir, lista de tipos suportados em Python.
1, -2 Inteiros
1.5, 2. Ponto Flutuante
0o14253 Octal
0b01101 Binrio
0x9ff Hexadecimal
3 + 4j Complexos
2.1.2 Atribuio de Varivel
Tambm a atribuio de varivel simples em Python. No necessrio declarar o tipo
da varivel, uma vez que a atribuio emPython o relacionamento entre objetos, procedimento
que pode ser facilmente desfeito.
Figura 2.1: Variveis em Python.
Por isso que uma varivel em Python pode receber qualquer tipo e qualquer objeto,
mesmo depois de inicializada. Chamamos isso de tipagem dinmica (LUTZ, 2009).
17
1
2 v a r i a v e l = 1 # r ecebendo i n t e i r o
3 v a r i a v e l = p i l h a ( cont eudo ) # r ecebendo um o b j e t o
4 v a r i a v e l = "Bom Di a ! " # r ecebendo s t r i n g
5
6 p r i n t v a r i a v e l # i mpr i mi ndo o v a l o r "Bom Di a ! " na t e l a
Cdigo 2.4: Exemplo de atribuio de varivel
Por ser uma linguagem interpretada, Python possui um coletor de lixo, que aps notar o
desuso de um objeto ir desaloc-lo da memria (LUTZ, 2009). Da no preciso se preocupar
com a destruio de objetos, como acontece em C++, nem preciso se preocupar com inmeras
atribuies diferentes mesma varivel. Por outro lado no uma prtica comum utilizar uma
varivel para aceitar todo tipo de atribuio, j que, por questes de legibilidade, uma varivel
deve esclarecer bem o tipo de objeto que deve receber. Assim o cdigo 2.10 logo abaixo seria
totalmente ininteligvel, ainda que funcional.
1
2 i da de = 15 anos
3 i da de = Be a t r i z Abreu
4 i da de = Pes s oa ( 15 , Be a t r i z )
Cdigo 2.5: Exemplo confuso de atribuio de varivel.
O cdigo acima, caria muito mais inteligvel se fosse escrito de outra forma, como se
segue no 2.6.
1
2 i da de = 15
3 nome = Be a t r i z Abreu
4 pe s s oa = Pes s oa ( i dade , nome )
Cdigo 2.6: Exemplo corrigido de atribuio de varivel.
A questo sobre legibilidade e qualidade de cdigo ser mais detalhadamente tratada na
seo 4.3 deste trabalho.
2.1.3 Strings em Python
Como tudo em Python um objeto, as strings so tambm objetos. E como todo objeto,
possuem mtodos. Em Python, as strings possuem diversos mtodos e diversas maneiras de
declarao que facilitam seu uso. Claro que, como toda linguagem, as strings so matrizes
de caracteres e por isso possuem operaes tipicamente associadas a matrizes. Enumeremos
algumas.
18
Atribuio string_1 = "Ol!"
Concatenao string_1 + string_2
ndice da string string_1[indice]
Tamanho da string len(string_1)
Fatia da string string_1[i:j]
Multiplicao string_1 * 2
A concatenao da string retorna uma string que composta pelos dois valores seguidos
das strings concatenadas.
1 s t r i n g _ 1 = ga t o
2 s t r i n g _ 2 = mal hado
3
4 s t r i n g _ 3 = s t r i n g _ 1 + s t r i n g _ 2 # s t r i n g _ 3 pos s ui o v a l o r " gat omal hado "
Cdigo 2.7: Concatenao de strings.
O operador do ndice retorna o caractere que se encontra na posio fornecida entre as
chaves.
1 s t r i n g _ 1 = ga t o
2 s t r i n g _ 1 [ 2 ] # Ref er e s e ao c a r a c t e r e t
Cdigo 2.8: ndice de strings.
J a funo len, padro em Python, retorna o comprimento da string.
1 s t r i n g _ 1 = ga t o
2 l e n ( s t r i n g _ 1 ) # r e t o r n a 4
Cdigo 2.9: Comprimento de strings.
Caso haja necessidade de repetir a mesma string diversas vezes, basta que para isso
utilize-se um multiplicador.
1 s t r i n g _ 1 = ga t o
2 s t r i n g _ 1 3 # Ret or na g a t o g a t o g a t o
Cdigo 2.10: Exemplo confuso de atribuio de varivel.
2.1.4 Listas e Dicionrios
Trabalhar com listas em Python bastante prtico, pois a linguagem oferece uma inni-
dade de recursos que facilitam sua utilizao pelo programador.
19
Para instanciar uma lista, basta que coloque seus elementos entre chaves em uma atri-
buio conforme o exemplo abaixo:
1 el ement o_1 = 1
2 el ement o_2 = " s t r i n g "
3 el ement o_3 = Fa l s e
4 l i s t a = [ el ement o_1 , el ement o_2 , el ement o_3 ]
Cdigo 2.11: Exemplo de criao de listas.
Como demonstrado acima, uma lista pode conter elementos de diversos tipos e at
mesmo objetos. O tamanho da lista pode ser obtido atravs da funo len().
1 l e n ( l i s t a )
Cdigo 2.12: Exemplo de obteno do tamanho de listas.
Outras funcionalidades so listadas abaixo:
lista_1 + lista_2 Concatena duas listas
lista_1.remove(ndice) Remove o elemento no ndice indicado
L[ndice] Retorna o elemento do ndice indicado
H diversos outros mtodos interessantes para o tratamento de listas, mas que por ques-
tes de escopo no sero mencionados.
Outra estrutura de dados bastante comum em Python so os dicionrios que uma cole-
o desordenada de elementos, na qual cada elemento possui sua chave e poder ser acessado
atravs dela (LUTZ, 2009).
1 d i c i o n a r i o = { spam : 2 , ham : 1 , eggs : 3}
2 el ement o = d i c i o n a r i o [ ham]
Cdigo 2.13: Utilizao de dicionrios. Fonte: (LUTZ, 2009) .
No exemplo acima, a varivel "elemento"conter o valor "2", j que no dicionrio, o
valor "2"est associado chave "spam".
2.1.5 Classes e Objetos
Apesar de poder ser utilizada como linguagem estruturada, Python uma linguagem
essencialmente orientada a objetos. Para criar uma classe no difcil.
1 # codi ng : ut f 8
2 c l a s s Bol a ( o b j e c t ) :
3 def _ _ i n i t _ _ ( s e l f , cor , di a me t r o ) : #Mtodo c o n s t r u t o r
4 s e l f . cor = cor
20
5 s e l f . di a me t r o = di a me t r o
6
7 def r e t o r n a _ c o r ( s e l f ) : #Mtodo que r e t o r n a a cor da Bol a
8 r e t u r n s e l f . cor
9
10 def t r o c a _ c o r ( s e l f , nova_cor ) : #Mtodo de r e t o r n o va z i o
11 s e l f . cor = nova_cor
Cdigo 2.14: Classes em Python.
Podemos notar diversas vantagens em Python com a classe "Bola". Uma delas que no
h necessidade de declarar os atributos da classe. Uma outra vantagem que a declarao de
mtodos bastante limpa e legvel. Essas caractersticas que tornam Python to diferente das
linguagens comuns. Para utilizar de herana, basta que coloque-se o nome da classe pai entre
os parnteses na declarao da classe lha.
2 c l a s s Cl a s s e _ f i l h a ( Cl a s s e _ p a i ) :
3 def _ _ i n i t _ _ ( s e l f ) :
4 # i n s t a n c i a a c l a s s e
Cdigo 2.15: Classes em Python.
2.2 Sonar
O Sonar trata-se de uma ferramenta para testes automatizados com a qual possvel
analisar a qualidade do cdigo desde a arquitetura at a complexidade, passando por anlise
de erros e qualidade de comentrios. Isso quer dizer que o Sonar torna o desenvolvimento de
software muito mais seguro por quanticar diversas caractersticas do projeto de software.
Atualmente h suporte para anlise de mais de 20 linguagens. Contudo a linguagem
padro para o Sonar java. Para que procedssemos neste trabalho, foi necessria a instalao
de um plugin que permitiu a anlise de projetos em Python.
O Sonar roda como um servidor web, facilitando os testes de integrao contnua. Toda-
via utilizamos o Sonar em uma mquina local que testa os projetos localmente. Aps executar
os testes, basta que se acesse o endereo local na porta 9000 atravs de um navegador web para
observar os resultados.
Acima podemos observar a tela inicial do Sonar aps terem sido analisados alguns pro-
jetos. direita embaixo podemos ver um grco que mostra visualmente a relao entre os
tamanhos dos mdulos em linhas de cdigo. Logo acima encontra-se a lista dos projetos anali-
sados. Clicando no nome do projeto analisado, surgir uma tela com diversas informaes como
21
Figura 2.2: Tela inicial do Sonar.
quantidade total de linhas do projeto, quantidade de classes e mtodos, bem como informaes
sobre cobertura de Unittests e violaes de qualidade.
Figura 2.3: Anlise oferecida pelo Sonar.
Tambm so informados os nveis de complexidade e porcentagem de violaes. Logo
abaixo poder ser observado um relatrio que descreve as violaes, seus motivos e a forma de
correo. Todas essas informaes visam o aumento da qualidade do projeto.
A anlise composta no s de valores numricos, bem como de grcos e nveis de
gravidade dos problema detectados.
Idealmente, o Sonar um mecanismo para integrao contnua, mas isso no impede
sua utilizao em outras metodoligas de engenharia. Porm preciso observar que muitas das
22
Figura 2.4: Violations Drilldown.
suas funcionalidades que visam auxiliar a integrao contnua seriam descartadas.
O Sonar funciona atravs de um servidor, de forma que os membros da equipe no
precisam se encontrar no mesmo local para a atualizao do software. Isso permite que o
software seja constantemente construdo e testado ao mesmo tempo. O ganho de ecincia
nesse mtodo surpreendente.
Muitas empresas e equipes de desenvolvimento podem se beneciar pela utilizao do
Sonar em seus projetos. Certamente com o auxlio de outros recursos como softwares de geren-
ciamento e gesto, a qualidade tende a aumentar signicativamente.
3 ENGENHARIA DE SOFTWARE
Esse captulo fala sobre uma disciplina da Cincia da Computao, a Engenharia de
Software bem como descrever seus aspectos e evoluo ao longo dos anos.
3.1 Denio
Ao se lanar no estudo de uma cincia, a primeira coisa a se fazer buscar sua denio,
a m de que conhecendo o que se estuda possa-se prosseguir corretamente no desenvolvimento
da atividade de estudar. A cincia o conhecimento das coisas pelas suas causas. A fsica,
por exemplo, buscar conhecer o funcionamento das coisas materiais atravs das relaes de
causalidade entre elas. J a arte um conjunto de conhecimentos que visa regular uma atividade
exterior. Por isso que ao conjunto dos diversos conhecimentos que dirigem a composio de
uma msica, chamamos de arte (GARDEIL, 1967).
Ento se toda engenharia uma arte, a Engenharia de Software tambm o ser e como
toda arte, possui disciplinas como a programao e a anlise orientada a objetos, que no passam
de tcnicas para atender ao propsito bsico da engenharia que atender alguma necessidade
humana, portanto sub-engenharias (PRESSMAN, 2010).
Mas o que seria software, o objeto de tal engenharia? Segundo Pressman (2010), pode-
mos chamar de software trs coisas distintas:
Instrues de computador que quando executadas produzem a funo e o desempenho
desejados;
Estruturas de dados que possibilitam que os programas manipulem adequadamente a in-
formao;
Documentos que descrevem a operao e o uso dos programas.
Nem sempre as denies formais so sucientes para elucidar o que a coisa (GAR-
DEIL, 1967). Por isso a descrio das caractersticas do software podem nos auxiliar a precisar
o que engenharia de software.
24
Embora, sob certo aspecto, a produo do software seja semelhante a produo do hard-
ware, o software um produto drasticamente diferente do hardware. Isso vai afetar signica-
tivamente a denio de engenharia de software em detrimento da denio de engenharia de
hardware (PRESSMAN, 2010).
O software desenvolvido ou projetado por engenharia, no manufaturado no sentido
clssico.
Software no se desgasta.
A maior parte do software feita sob medida em vez de ser montada a partir de compo-
nentes existentes.
Ainda preciso considerar que o software apenas uma parte de um sistema da informa-
o, a saber a parte programvel (FILHO, 2003). O hardware, as bases de dados e a arquitetura
de rede tambm so componentes de tais sistemas.
Deste modo preciso reconhecer que o engenheiro de software um prossional que
idealmente trabalhar em conjunto com outros engenheiros, mas que na prtica, ter que dar
conta de outras atividades que no concernem ao desenvolvimento de software, como a ad-
ministrao de banco de dados ou implementaes de redes. Fiquemos com a denio de
Engenharia de Software por Sommerville (2011)."Engenharia de Software a disciplina da en-
genharia preocupada com todos os aspectos da produo de software desde a concepo at a
fase de entrega (...)"
3.2 Histrico
Quando a informtica surgiu, o desenvolvimento de software era uma questo secun-
dria. A maior parte da engenharia de sistemas da informao se dedicava a construo do
hardware que era bastante especco para desempenhar uma funo. A produo do software
se concentrava na programao de rotinas que iriam operar aquele hardware especco. J a
produo do hardware se preocupava em diminuio do custo de processamentos e de armaze-
nagem.
O programador de software era uma prosso bastante imprecisa. Frequentemente o
programador aprendia empiricamente por tentativa e erro e na realidade no haviam cursos
dedicados a isso. O programador era muitas vezes um engenheiro eltrico que decidiu fazer in-
curses na rea da informtica (PRESSMAN, 2010). No havia uma prosso de programador,
nem a prosso de engenheiro de software. O fato que as solues propostas pela engenharia
de software ainda eram muito embrionrias e muito incertas.
25
Contudo, logo aps o desenvolvimento dos circuitos integrados, foi possvel um salto
no desenvolvimento de software, de forma que s atravs de um software bem projetado que
seria possvel aproveitar o potencial atingido pelo hardware. E de fato, as preocupaes atuais
em torno da aquisio de sistemas da informao no giram em torno do hardware, mas sim do
software (PRESSMAN, 2010).
A Engenharia de Software evoluiu ao longo dos anos, o que permitiu a classicao do
software em cinco grupos de gerao. De acordo com Pressman (2010), independentemente da
gerao em que se encontra, a engenharia de software deve lidar com os mesmos problemas:
A sosticao do software comumente ultrapassa a capacidade de construir um software
que extraia o potencial do hardware;
A capacidade de construir programas no acompanha a demanda do produto de software;
A manuteno de software ameaada por projetos ruins e recursos inadequados.
3.2.1 Software de Primeira Gerao
Como dito anteriormente, o hardware era o principal objeto da engenharia de sistemas da
informao. O software era desenvolvido pelo usurio do hardware, uma organizao comercial
ou instituio de pesquisa.
Como no havia rotatividade de emprego, o gerente no se preocupava na perda do pro-
gramador, de forma que s vezes um s homem possuia a cincia, a arte e a documentao do
sistema dentro da sua cabea, como se o desenvolvimento do software no possusse uma admi-
nistrao metdia. A consequncia disso era o aumento drstico do custo e o atraso sistemtico
do prazo (PRESSMAN, 2010).
3.2.2 Software de Segunda Gerao
J a segunda gerao dos softwares se constitui por uma evoluo considervel em re-
lao a gerao anterior. Agora, os sistemas eram multiprogramveis e multiusurio, o que
determina uma mudana signicativa no projeto e implementao de sistemas. Com isso, os
softwares passaram a ser distribudos em quantidade, ao invs de serem altamente personaliza-
dos.
Alm disso, com a evoluo dos sistemas multiprogramveis, o cdigo se tornara alta-
mente complexo e o nmero de linhas aumentara consideravelmente. Tambm, pelo fato de
serem amplamente distribudos, a manuteno e correo de erros num software de milhares
de cdigos no era mais uma tarefa simples. Tudo isso contribuiu para o aumento signicativo
26
no uso de recursos, de forma que a engenharia de software comea a tomar forma mais precisa
alm de ter sua necessidade aumentada (PRESSMAN, 2010).
3.2.3 Software de Terceira Gerao
Os recursos no poderiam parar de evoluir. Por isso que com a diminuio fsica do
tamanho dos recursos de hardware representaram o incio de uma nova gerao. Agora, com o
advento dos computadores pessoais, um novo tipo de software deve ser projetado, impactando
na Engenharia de Software.
A questo que envolve a evoluo tecnolgica do hardware atinge diretamente a enge-
nharia de software, j que o software no pasa de um potencializador dos recursos oferecidos
pelo hardware e que com uma fonte gigantesca de recusos no era qualquer software que pode-
ria realizar este trabalho.
Neste contexto, uma espcie de crise se agiganta no horizonte: a Engenharia de Software
ao produzir um produto complicadssimo, constantemente se v diante de atrasos inevitveis e
aumentos de custo exorbitantes.
Por outro lado, as empresas produtoras de software produzem e vendem centenas de
milhares de software ao contrrio das empresas da segunda e primeira gerao que praticamente
faziam um software diferente a cada necessidade (PRESSMAN, 2010).
3.2.4 Software de Quarta Gerao
Nessa quarta gerao, h o advento de tcnicas revolucionrias na produo de software.
Orientao a objeto, sistemas distribudos e inteligncia articial, todos j no mais eram obje-
tos de estudos cientcos nas universidades, mas se tornaram tcnicas reais para as empresas de
software.
Agora a fabricao do software poderia ser encarada independentemente da fabricao
do hardware e sobretudo se encontrava como um servio oferecido por empresas que no iriam
se beneciar diretamente da construo do software (PRESSMAN, 2010).
3.2.5 Software de Quinta Gerao
Vivemos atualmente sob o impulso do software de quinta gerao. No s as tcnicas
de de orientao a objeto, sistemas distribudos e inteligncia articial se tornaram as tcnicas
dominantes no mercado, como tambm a engenharia evoluiu para sua forma de produo just-
in-time, ainda que diversas fbricas de software ainda no a utilizem.
27
Diversos modelos de capacitao prossional foram criados para garantir atravs da
padronizao a diminuio de disperdcios e otimizao do processo de produo de software.
A internet se tornou um recurso costumeiro e ao mesmo tempo imprescindvel para o
funcionamento das grandes incorporaes, de maneira que o competente prossional de soft-
ware um requisito obrigatrio para ganhar fatias do mercado (PRESSMAN, 2010).
3.3 Ciclo de Vida do Software
Ainda que as tcnicas de engenharia tenham evoludo signicativamente, isso no quer
dizer que seus princpios tenham sido mudados. A engenharia ainda se dirige para obter os
mesmos resultados e dirigida pelos mesmos princpios que nos primrdios da sua existncia,
anal senso comum que todo projeto precisa ser planejado para obter sucesso e que todo ple-
najamento precisa ser executado. Desde modo que classicamente a engenharia de software
dividiu a produo do seu produto em etapas, por exemplo: Anlise dos requisitos, Planeja-
mento, Implementao, Testagem e Evoluo do software.
Figura 3.1: O Ciclo de Vida do Software. Fonte: Wikipedia(2013)
A clssica gura acima demonstra o ciclo de vida do software. Apesar de ser um modelo
cclico (em que o nal coincide sempre com o recomeo), no est em total desacordo com as
metodolias geis em que as etapas do ciclo tendem a ser simultneas e a testagem precede a im-
plementao. Contudo h graus de granularidade para aplicao desses conceitos. possvel,
por exemplo, que equipes que abordam metodologias geis para o desenvolvimento do software
apliquem o modelo em cascata a cada iterao, que idealmente dura em torno de uma semana.
Mas tambm possvel, e isso acontece com os adeptos da metodologia XP, que dentro da ite-
28
rao os processos tendam a ser realizados concomitantemente (ASTELS; MILLER; NOVAK,
2002).
A diferena bsica consiste no fato de que as metodologias clssicas possuem seu foco
no planejamento e nas metodologias geis o foco a entrega imediata de valor ao cliente.
3.4 Qualidade do Software
Todas as tcnicas e conceitos da Engenharia de software visam aumentar a segurana,
reduzir custos e defeitos. Esses objetivos no possuem outra nalidade seno o aumento da
qualidade do produto, que por ser um produto bastante intangvel, tem sua qualidade difcil de
ser medida.
De acordo com a Associao Americana de Controle da Qualidade, qualidade a to-
talidade das caractersticas de um produto que determina a sua habilidade em satisfazer um
determinado usurio. De forma que para saber metodicamente se um produto tem qualidade
preciso que sejam levantados os desejos gerais dos usurios. Deste modo so criadas normas
que so como leis que os produtos devem seguir para adquirir qualidade durante sua produo.
As normas so criadas e atualizadas por diversas organizaes internacionais que es-
tabelecem normas aps estudo tcnico de cada caso. Aqui no Brasil, por exemplo, temos o
INMETRO, o NBR ISO, o MPS-Br entre outras coisas. E como o mercado consumidor tem
aumentado sua exigncia, a estratgia de oferecer qualidade tem sido a preferida por muitas
empresas do ramo de software.
4 QUALIDADE DE SOFTWARE
Este captulo dene o que qualidade de software, apresenta algumas normas referentes
a qualidade de software e aborda a melhoria da qualidade de software atravs da melhoria do
cdigo.
4.1 Denies de Qualidade
Uma das tarefas mais rduas no processo de engenharia determinar a qualidade do
produto. Em geral quando tal produto simples, sua qualidade pode ser mensurada facilmente.
No caso de uma lmpada, basta saber o consumo, capacidade e durabilidade para determinar
sua qualidade. Contudo em produtos mais complexos essa determinao pode ser mais com-
plicada. Para facilitar a medio possvel somar os valores quantitativos dos componentes do
produto e obter um medidor de qualidade. Assim se, por exemplo, num painel composto de
quatro lmpadas de sessenta watts obtm-se um consumo de duzentos e quarenta watts. Mas e
quando o produto altamente abstrato e complexo como o caso do software (KOSCIANSKI;
SOARES, 2007)?
O primeiro a denir qualidade na indstria moderna foi Ford. Nas suas empresas, quali-
dade signicava um atendimento a especicao do produto. Isso quer dizer que a qualidade de
um parafuso, por exemplo, estava relacionada com o conjunto de diretrizes que esse parafuso
deveria ter para garantir sua usabilidade (WOMACK; JONES; ROOS, 2007).
Apesar disso com o desenvolvimento das tcnicas de engenharia do produto, uma nova
denio de qualidade foi assumida. Nessa nova viso, qualidade seria a conformidade do pro-
duto com os seus requisitos (KOSCIANSKI; SOARES, 2007). Isso se d principalmente pelo
desenvolvimento da gerncia de requisitos durante a dcada de 80. Ainda que essa denio re-
presente um avano na evoluo da qualidade, uma nova denio pde ainda ser desenvolvida.
Com as pesquisas dos processos industriais japoneses, vericou-se que um novo pro-
blema sustentava a qualidade do produto, a usabilidade. Isso quer dizer, em termos mais
simples, que a qualidade precisaria do cliente para ser julgada (CHAMBERS; JONHSTON;
SLACK, 2009).
30
No atual sistema de mercado, o objetivo da empresa no somente produzir um produto
bem convel, mas produzir um produto bem convel na tica do cliente. O produto deve sa-
tisfazer as necessidades e interesses do cliente, pois s assim que o produto se torna altamente
rentvel. No campo da engenharia de software, isso pode ser traduzido como baixa ocorrncia
de erros, atendimento das necessidades do cliente e a alta taxa de lucratividade que a aquisio
do software pode oferecer ao cliente.
Em termos precisos, qualidade satisfazer o cliente. Com isso no se pretende destituir
as outras denies do posto, mas sobretudo alicera-las sob um ponto comum. Anal tanto
atender as especicaes do produto, como props Ford, quanto a conformidade do produto
aos requisitos , como props Crosby, tm por nalidade garantir a satisfao do cliente. Desta
maneira preciso que se investigue as necessidades do cliente para que o produto de software
possa atende-las. Um mdulo que calcule rotas de foguetes no tem serventia alguma na pro-
duo de um sistema para um cliente que quer apenas gerenciar as nanas mensais de um
supermercado (KOSCIANSKI; SOARES, 2007).
Se o objetivo da qualidade de software atender as necessidades do cliente preciso ter
em conta que tipo de necessidade est em jogo. assim o primeiro objeto da qualidade de soft-
ware a ocorrncia de bugs. Alguns bugs podem causar resultados catastrcos como prejuzo
nanceiro ou at perda de vidas humanas, outros podem causar apenas pequenas diculdades e
alguns raramente sero alvo de preocupaes (KOSCIANSKI; SOARES, 2007).
famoso o caso do foguete Ariane 501 em que uma falha sistmica signicou a perda
de trezentos milhes de dlares. Tambm muito citado o caso do Therac-25, um equipamento
radiolgico em que erros do sistema causaram a morte de cinco pacientes. Apesar disso, as
falhas mais visveis so os travamentos, pois o sistema ca imediatamente inutilizvel para o
usurio (KOSCIANSKI; SOARES, 2007).
O controle dessas falhas deve ser medido de acordo com a necessidade. Na produo
de um sistema comercial, por exemplo, uma taxa de ocorrncia de erro na ordem de 1% pode
no abalar a gerncia, uma vez que muitas vezes a correo de certos bugs pode signicar
o aumento de risco e mudanas radicais no sistema. Se h satisfao em 99% dos casos,
sinal que a qualidade desse sistema comercial excelente. Por outro lado, sistemas como o
do Therac-25 e o do Ariane 501 devem ter suas falhas reduzidas idealmente a 0, uma vez
que perdas nanceiras e sobretudo perdas humanas so irreversveis. Tal fato fora o gerente
a testar o sistema exaustivamente a m de encontrar todas as ocorrncias de erro possveis
(KOSCIANSKI; SOARES, 2007).
31
4.2 Padres de Qualidade
Sendo a qualidade o atendimento dos requisitos, das especicaes ou das necessidades
do cliente, o fato que s possvel medir a qualidade de acordo com certos parmetros. Assim,
na indstria fordista o produto era comparado com uma lista de especicaes quer permitiam
julgar sua qualidade. Na dcada de 90 a indstria passou a relacionar o produto com a lista de
requisitos fornecida pelo cliente para julgar sua qualidade. Por outro lado no basta que cada
sistema de software atenda a parmetros particulares, j que em inmeras vezes os softwares
interagem com outros softwares e com diferentes usurios. Esse fato demonstra a necessidade
da estipulao de normas tcnicas que viabilizem a determinao da qualidade do produto de
software e essas normas.
A necessidade de estabelecer padres de qualidade a nvel mundial fez com que logo na
dcada de 40, criasse-se uma instituio para organizar padres de qualidade de nvel mundial.
A instituio levou o nome de International Organization for Standardization e suas denies
vo desde padres de pesos e medidas at a padronizao de qualidade em sistemas da infor-
mao. As normas criadas por essa instituio recebem o nome de ISO(do grego igualdade),
seguidas de um cdigo numrico que as identica. Assim a norma ISO 9000 refere-se a normas
de qualidade em ambientes de produo.
Posteriormente a ISO em conjunto com o IEC (Iternational Eletrotechnical Commis-
sion) formou a JTC1 (Joint Technical Comitee 1). O JTC1 uma subcomisso que cuida de
normas referentes a tecnologia da informao. Especialmente na rea de qualidade de software
destacam-se a ISO 12207 e a ISO/IEC 25000 (KOSCIANSKI; SOARES, 2007).
A norma ISO/IEC 12207 estabelece um conjunto de padres para reger o ciclo de vida
do software, isto , regular o desenvolvimento e a manuteno de software. J a norma ISO/IEC
25000 visa estabelecer os meios para garantir a qualidade de software. Ela consiste numa fuso
de diversas outras normas com a mesma nalidade. (ISO, 2013)
Os critrios utilizados por essas normas para detectar a qualidade do produto de soft-
ware so chamados de dimenses da qualidade. So elas a usabilidade, manutenibilidade e
funcionalidade. A usabilidade diz respeito facilidade do usurio para utilizar o software e a
manutenibilidade facilidade para o software ser manutenido. J a funcionalidade uma di-
menso que julga se o software oferece as funes adequadas aos requisitos, isto , se o software
funciona. (PRESSMAN, 2010)
4.3 Qualidade do cdigo-fonte
Sob certo aspecto, pode-se dizer que o software ainda um produto artesanal, j que
sua construo depende em boa parte da habilidade tcnica individual dos programadores. Esse
32
fato produz um impacto profundo na forma de se imprimir qualidade ao produto de software.
O produto meramente manufaturado como automveis e eletrodomsticos possui componentes
que podem ser feitos em srie. Mas o produto de software muitas vezes possui um componente
que no pode ser produzido em srie. Assim para cada projeto de software preciso enfren-
tar uma incerteza maior do que na construo civil, por exemplo (KOSCIANSKI; SOARES,
2007). Alm disso, considerando que a legibilidade, ecincia e eccia so produtos de um
programador humano, isto determinar em grande parte a qualidade do produto.
Como exemplo pode-se utilizar o caso de um cdigo mal comentado(KOSCIANSKI;
SOARES, 2007). Quando o software de tal cdigo precisar de manuteno, provavelmente
um outro programador ter que compreend-lo e isso quer dizer que com a m edentao ser
muito mais dispendioso (tanto nanceiramente quanto intelectualmente) corrigir ou modicar
tal software. O caso relatado envolve apenas um aspecto da programao de computadores, que
a documentao. Contudo diversos outros elementos iro, em conjunto, compor aquilo que
chamamos de cdigo de software e consequentemente podero ser julgados, em conjunto ou
separadamente, segundo sua qualidade. Assim dentre os diversos aspectos a serem observados
para aferir a qualidade de software, um deles a qualidade de cdigo e dentre os diversos
elementos para averiguar a qualidade de cdigo, um deles a taxa de documentao. Anal,
como pretenderam Abelson, Sussman e Sussman (1996), um cdigo escrito mais para seres
humanos lerem do que para computadores. E de fato, mquinas s compreendem cdigo de
mquina.
Um outro fator para determinar a qualidade de cdigo segundo a legibilidade a escolha
da linguagem de programao. Sistemas voltados a resoluo de clculos precisam ter seus
cdigos mais prximos da notao matemtica, o que facilita imensamente na interpretao do
signicado do cdigo. J sistemas voltados para a resoluo de problemas empresariais teriam
sua interpretao e manuteno totalmente atrapalhada se fossem produzidos com linguagens
funcionais. Isso tudo sem mencionar o impacto que a escolha de uma linguagem pode ter na
performance do sistema.
Deste modo, ca claro que o cdigo do sistema vai ser interpretado no s pela mquina,
como pelo homem e que, como toda linguagem, est sujeita a desentendimentos. A esses
desentendimentos damos o nome de "gap semntico"ou ainda "distncia semntica", para um
termo mais aportuguesado (KOSCIANSKI; SOARES, 2007).
Como programar uma tarefa intelectual, os problemas do cdigo so resolvidos por in-
divduos, ainda que esses indivduos se renam em equipes para resolver problemas de escopo
mais genrico, isso no quer dizer que o mesmo cdigo desenvolvido por diversos membros
da equipe. E por mais que as linguagens de programao evoluam, ainda assim os programa-
dores encontram os mesmos problemas h dcadas, estes incluem traduo de especicaes
em cdigo, anlise de cdigo escrito por outros programadores e modicao de cdigo para
33
correo de erros.
Esses trs problemas esto diretamente relacionados com o gap semntico, j que as
diversas linguagens de programao no s possuem um vasto repertrio semntico, como tais
repertrios so diferentes entre as linguagens. Isso quer dizer que um programador C++, ainda
que bastante experiente, pode no entender um cdigo escrito em Python, por exemplo.
A partir disso no se pode entender que o melhor programador detm conhecimento su-
percial em diversas linguagens, mas sim aquele que possui conhecimento profundo em uma
linguagem especca. O conhecimento profundo de uma linguagem tambm prepara o pro-
gramador para situaes extremamente econmicas em software, o que de suma importncia
para os projetos de desenvolvimento. Signica que o desconhecimento de certas funcionali-
dades de uma linguagem pode obrigar o programador a criar cdigos maiores, redundantes ou
inecientes.
Dois so os motivos para a diminuio da compreensibilidadede do cdigo: presso do
ambiente de trabalho e falta de treinamento (KOSCIANSKI; SOARES, 2007).
Em diversas ocasies, o programador escreve um cdigo que funciona, mas que torna
sua compreenso muito difcil. o que chamamos popularmente de cdigo-espaguete. A
grosso modo, o melhor jeito de evitar tais diculdades seria atravs da escrita mais simples
possvel. Um cdigo deve evitar procedimentos rebuscados, no devido a funcionalidade, mas
devido a legibilidade.
A primeira questo sobre legibilidade a ser abordada a nomenclatura de identicado-
res. Um identicador de varivel deve ser nomeado de forma bastante sugestiva e que indique
semanticamente o que ele representa. Deste modo ao instanciar uma classe Pessoa em um
objeto p muito menos prudente do que instanciar tal classe em um objeto pessoa. Em sis-
temas extensos, pode-se perder o referencial do objeto e/ou varivel a ponto de o programador
se perguntar frequentemente o que seria tal objeto, ocasionando uma perda de tempo ao buscar
a resposta para essa pergunta. Por outro lado, um cdigo est muito mais documentado se as
variveis possurem nomes signicativos. (KOSCIANSKI; SOARES, 2007).
Uma soluo para tal problema, seria a padronizao de nomenclatura, embora no haja
ainda um padro universalmente aceito para tal. Ainda assim, empresas podem criar seus pr-
prios padres para facilitar o entendimento dentro da organizao, como , por exemplo, preceder
o nome de toda varivel relacionada a um ponteiro com o tipo da varivel. H ainda a nomen-
clatura hngara, desenvolvida por Simonyi, que consiste em utilizar prexos contendo os tipos
das variveis na criao da mesma. Apesar da evoluo signicativa, esse tipo de padro no
facilita a compreenso global do cdigo, isto , a nomenclatura hngara discrimina o tipo da
varivel, mas no diz sua nalidade (KOSCIANSKI; SOARES, 2007).
A segunda questo sobre legibilidade a que envolve recuos, espaamentos e alinha-
34
mentos. Em certas linguagens dinmicas como o caso de Python, a edentao pode mudar
completamente o comportamento do programa e outras vezes pode at gerar erros. Ao contr-
rio das linguagens baseadas em C, em tais linguagens o espaamento um elemento do cdigo
(LUTZ, 2009).
Introduzir linhas em branco para separar blocos de cdigo tambm uma prtica bas-
tante prudente. como fazemos em linguagem corrente ao iniciar um novo pargrafo. Outra
prtica bastante promissora o alinhamento de vrgulas e de sinais de atribuio. Um progra-
mador mal treinado se depararia estranhamente com tal sugesto, j que o resultado do cdigo
seria o mesmo no caso em que tais sinais estivessem desalinhados. Anal, repetimos, o cdigo
no escrito para a mquina, mas sim para outros programadores lerem.
1 Pr e pa r e dSt a t e me nt s t a t e me n t = new Pr e pa r e dSt a t e me nt ( ) ;
2 c onne c t i on = new Connect i on ( ) ;
3 s t a t e me n t = c onne c t i on . g e t St a t e me n t ( ) ;
4 }
Cdigo 4.1: Alinhamento de sinais de atribuio.
A terceira questo sobre legibilidade e que a facilita em muito a utilizao de editores.
Se admitirmos que as tcnicas mencionadas acima facilitam a interpretao do cdigo, devemos
admitir que a agilizao para empregar tais tcnicas de suma importncia. Ora, nada melhor
para agilizar tarefas do que a prpria informtica atravs do uso de ferramentas adequadas. Em
diversos editores de cdigo a edentao automtica. Outros ainda oferecem suporte ao uso
de templates, que automatizam a digitao repetitiva de cdigos. Por isso, qualidade de cdigo
est diretamente associada com ferramentas de edio (KOSCIANSKI; SOARES, 2007).
Ainda que a escrita seja clara e bem organizada, isso no quer dizer que um cdigo seja
entendido facilmente. Pode ser que o sistema envolva conceitos complexos e avanados. Nesses
e em outros casos se faz necessrio a utilizao de documentao do software, um aparato
tcnico que explicar aos programadores o funcionamento interno do sistema. As modernas
metodologias geis sugerem sempre que a documentao do sistema seja feita atravs de cdigo
bem escrito, identicadores apropriados e do uso extensivo de comentrios no cdigo, em suma
deve-se tentar criar toda a documentao no cdigo-fonte (ASTELS; MILLER; NOVAK, 2002).
4.4 Mecanismos para melhoria de cdigo-fonte
4.4.1 Documentao do cdigo
Quando o programador insere comentrios adequadamente em seu cdigo-fonte, pos-
svel adotar uma ferramenta de documentao, como a Doxygen, capaz de analisar o cdigo-
fonte e capturar todas as informaes, depositando-as em um output que pode ser um arquivo
html ou pdf. Ela tambm pode gerar diagramas de herana e chamadas de subrotinas, de-
claraes de estruturas de dados e diversas listas alfabticas de dados do sistema que muitos
programadores experimentados no captariam rapidamente.
Eis um exemplo de cdigo:
35
1 / Thi s f u n c t i o n does a b s o l u t e l y not hi ng i mp o r t a n t . /
2 bool exempl o ( c ons t s t d : : s t r i n g &s t r ) {
3 r e t u r n t r u e ;
4 }
Cdigo 4.2: Exemplo de uso do doxygen
Tal cdigo se submetido Doxygen forneceria o resultado abaixo:
Figura 4.1: Sada do Doxygen. Fonte: Flip Code (2012)
Observa-se que o comentrio do cdigo-fonte foi extrado e includo na sada da docu-
mentao. O mtodo foi corretamente descrito conforme seu retorno e seus parmetros. Enm,
em casos de grandes cdigos, o Doxygen se manifestaria deveras lucrativo.
Conforme visto anteriormente, o uso de comentrios no deve ser poupado. Tambm foi
demonstrado o benefcio de padronizao nos cdigos. Ambos com a nalidade de melhorar
a qualidade do cdigo-fonte. A partir de tais propostas, surge a ideia de tambm melhorar a
qualidade dos comentrios, entendendo-se que o melhor meio para isso a padronizao de seu
formato. Em geral os comentrios padronizados devem apresentar informaes como descrio
da rotina, entradas, sadas, exemplos de uso, efeitos colaterais e casos no tratados. Obviamente
como qualquer outro comentrio, um comentrio padronizado ser exibido no resultado de
ferramentas como o Doxygen.
4.4.2 Refatorao
Tambm o que diminui signicativamente a qualidade do cdigo a duplicao de fun-
cionalidades, isto , escrever mais de uma funo para produzir resultados semelhantes. Nesse
caso o mais adequado criar uma funo mais abstrata que atenda a uma necessidade mais
genrica, o que chamamos de refatorao. O resultado um cdigo mais limpo e mais eciente
(ASTELS; MILLER; NOVAK, 2002).
4.4.3 Padronizao
A padronizao da escrita no suciente para garantir a qualidade de software. Mas a
padronizao de solues pode auxiliar em grande nmero a aumentar a qualidade do produto
36
de software. A padronizao de solues se d por trs meios: reuso de cdigo, comunidade de
desenvolvedores e por bibliotecas. Para tornar o reuso de cdigo mais efetivo, torna-se indis-
pensvel a utilizao de repositrios de cdigo, como o Github. J as comunidades de desen-
volvedores englobam uma srie de recursos como tutoriais e programas completos, que podem
diminuir sensivelmente o tempo e/ou complexidade do desenvolvimento (KOSCIANSKI; SO-
ARES, 2007).
Ainda h o recurso de bibliotecas de funes. Com as linguagens antigas, o desenvolvi-
mento de um sistema muitas vezes tinha que passar por uma fase em que eram desenvolvidas
estruturas de dados que no faziam parte do objetivo central do projeto. Isso signica perda
de tempo dobrada, j que tambm no faz sentido reinventar a roda. Obviamente as lingua-
gens modernas trataram de incluir diversas bibliotecas no s de estruturas de dados, como de
comunicao em rede, clculo numrico ou manipulao grca. Todos esses trs meios so
altamente necessrios para aumentar a qualidade do cdigo (KOSCIANSKI; SOARES, 2007).
4.4.4 Anlise de Complexidade
Quando um usurio se depara com a lentido do computador, a primeira coisa que lhe
vem cabea melhorar a capacidade fsica da mquina. Claro que isso pode ser feito, mas
quando um software mal construdo, provavelmente trocar de mquina no a melhor soluo.
De forma que o software mal feito em uma boa mquina pode ser uma soluo mais cara do
que um software bem feito em uma mquina mdia. Desse modo foram criados diversos meios
de analisar o cdigo e medir sua qualidade. Um desses meios a anlise de complexidade que
visa estabelecer o quanto um cdigo pode ser complexo.
Existe ainda um meio de medir a complexidade do cdigo que chamamos de comple-
xidade ciclomtica. Esse tipo de mtrica determina as possibilidades de execuo do software
de acordo com o nmero de caminhos de execuo. Se um software no possui excees e
s possui um caminho de execuo, sua complexidade ca medida em 1. Mas se ele j conti-
ver uma estrutura condicional de controle, possuindo dois caminhos portanto, ter seu nvel de
complexidade avaliado em 2. (A. J. SOBEY, 1997)
A complexidade ciclomtica determinada atravs de um grafo que representa graca-
mente os caminhos de execuo do cdigo-fonte. Por isso ela poder ser determinada tambm
por uma frmula matemtica que envolve a quantidade de ns e a quantidade de componentes
conectados, alm da quantidade de caminhos (A. J. SOBEY, 1997).
M = E - N + 2 x P
Em que M representa a complexidade ciclomtica, E representa a quatidade de cami-
nhos, N a quantidade de ns e P a quantidade de componentes.
4.4.5 Programao Defensiva
Com a nalidade de eliminar todas as possibilidades de erros, surgiu o conceito de pro-
gramao defensiva. Programao defensiva consiste na aplicao sistemtica de quatro tc-
nicas para diminuio de problemas relacionados ao cdigo. So elas: limitao de entradas,
compilao condicional, uso de excees e codicao estilizada (KOSCIANSKI; SOARES,
2007).
37
A primeira tcnica mencionada, limitao de entradas, sugere que nem toda entrada do
usurio deve ser recebida como input realmente. Isso quer dizer que em uma calculadora digital
no deve aceitar strings como parmetros para suas funes de soma. Isso diminui bastante a
possibilidade de erros, uma vez que em caso de dgito equivocado do usurio, o sistema no
retornar um valor errado, mas simplesmente ignorar o dado informado pelo usurio, podendo
at mesmo emitir um sinal de erro ao usurio.
A segunda tcnica mencionada, compilao condicional, se refere possibilidade de
um cdigo ser compilado diferentemente conforme a plataforma utilizada. O exemplo a seguir
mostra um pequeno trecho de cdigo que seria compilado de forma diferente caso o sistema
operacional fosse Unix ou Windows.
1 # i f d e f UNIX
2 / / Pr ocedi ment o A
3 # i f d e f WINDOWS
4 / / Pr ocedi ment o B
5 # e n d i f
Cdigo 4.3: Compilao condicional. Fonte: Koscianski e Soares (2007)
J a terceira tcnica mencionada, excees, bem conhecida pelos programadores de
linguagens mais recentes. Trata-se de um meio para evitar danos sistmicos em caso de uma
falha parcial. Em Python, o tratamento de excees bem simples, como pode ser demonstrado
a seguir.
1 x = 2
2 y = 3
3 t r y :
4 x+y
5 e xc e pt Va l ue Er r or :
6 p r i n t " Er r o ao somar . "
Cdigo 4.4: Exemplo de Exceo
No caso acima, aps atribudos valores a duas variveis, tentou-se executar uma soma. Caso a
soma no se proceda em tempo de execuo, o sistema levanta uma exceo e envia ao usurio
uma mensagem de erro customizada.
Finalmente h a quarta tcnica que chamamos de codicao estilizada. Os aspectos
dessa tcnica, de certa forma j mencionados acima fazem meno a padronizao do cdigo
de forma a tornar o cdigo mais claro e mais condizente com as funes da linguagem utilizada.
4.4.6 Testes de Software
Na rea de fabricao de automveis, antes da era Ford , os automveis eram produzidos
por artesos e eram testados pelos prprios usurios. Muitas vezes o automvel tinha que voltar
a ociena inmeras vezes para adaptaes e reparos, sem contar que muitos dos proprietrios
mantinham seus prprios mecnicos pessoais para manutenir e pilotar o carro diariamente. Isso
no s aumentava o tempo de produo, como podia deixar o usurio insatisfeito e a produo
e manuteno carssimas. J nas fbricas de Ford, os carros eram produzidos e testados antes
de serem colocados no mercado, o que aumentou consideravelmente a qualidade do produto
(WOMACK; JONES; ROOS, 2007).
38
Com software no poderia ser diferente. O software de qualidade precisa ser testado
am de ter seus defeitos detectados e por isso mesmo h uma grande necessidade de se estudar
o conceito.
Um meio de se avaliar a qualidade de um software saber se ele executa o requisito
pedido pelo cliente. Uma calculadora no pode fornecer uma diviso como resultado de uma
soma. No caso da apario de defeitos, precisa haver facilidade de correo de tais falhas.
E quando um usurio contrai uma diculdade imensa para manipular o software, este perde
qualidade. Assim foram criados diversos meios para testar a qualidade do software de acordo
com os critrios mencionados (SOMMERVILLE, 2011).
No princpio da engenharia de software, os softwares eram testados por uma equipe de
testes que manualmente inseria valores que pudessem ocasionar erros na sada. Obviamente
com a evoluo dos sistemas de informtica, tal tipo de operao comeou a car obsoleta. Da
que surgiram os primeiros softwares para facilitar a testagem (PRESSMAN, 2010).
Atualmente prefere-se testar durante o desenvolvimento do cdigo-fonte, a m de evitar
o maior nmero de erros possveis, por isso mecanismos de testagem para diversas linguagens
e muitas ferramentas automatizadas para teste tem sido desenvolvidos (ASTELS; MILLER;
NOVAK, 2002).
5 TESTES DE SOFTWARE
Se a qualidade do cdigo um aspecto to signicativo para medir a qualidade de soft-
ware e se para garantir a qualidade de qualquer produto precisa-se diminuir ao mximo sua
quantidade de defeitos, perceptvel que testes de software so de suma importncia para atin-
gir uma melhoria na qualidade do mesmo. Assim esse captulo visa explicar o conceito e o
fundamento dos testes de software tanto do ponto de vista terico, como do ponto de vista
prtico.
5.1 Defeitos
Como visto anteriormente, todo produto deve meticulosamente atender as necessidades
do cliente, incluindo produtos de software. H produtos cuja taxa de erro deve ser mnima como
o caso de medicamentos. Falta de controle na dosagem, por exemplo, pode at signicar a morte
do paciente. Tambm na rea de aviao, um pequeno erro pode signicar a perda de centenas
de vidas humanas. No so raras as notcias de desabamento de prdios, ao menos no Brasil. Em
todos esses casos a necessidade do cliente no foi atendida. s vezes a consequncia pode ser
apenas um mal estar generalizado em se tratando de comida de baixa qualidade. Outras vezes
pode signicar perdas humanas em nmero considervel. Por isso a qualidade dos produtos
deve ser procurada ao mximo e obtida por meios seguros.
A questo que o produto de software, na maioria dos casos, causa apenas perdas -
nanceiras, ainda que altas. Isso d uma certa margem de erros aos projetos. Tanto que os
programadores esto acostumados a escrever cdigo por tentativa e erro ou at mesmo deixar
certos erros semcorreo. Contudo inmeros defeitos de software so originados a partir da cor-
reo de outros erros (HAUSLER; LINGER; TRAMMELL, 1994). Isso quer dizer que, como
toda a engenharia, a engenharia de software deve se preocupar com a produo de software
correto desde a primeira vez.
Para assegurar que o software funcione corretamente, preciso revisar, inspecionar e
testar o software e a esse conjunto de processos chamamos de atividades de vericao e va-
lidao (SOMMERVILLE, 2011). Contudo h diferena entre validar e vericar. Validao
o processo de averiguar se as especies do software so condizentes com os requisitos do
cliente. Por outro lado, vericao o processo de averiguar se o software est de acordo com
tais especiaes (KOSCIANSKI; SOARES, 2007).
40
5.1.1 Identicao de Defeitos
Se a engenharia de software pretende construir um software sem defeitos, a primeira
tarefa seria descobrir que tipo de defeitos podem existir na construo de tal produto para que,
ajudado pela denio, tais defeitos possam ser mais facilmente encontrados e corrigidos. Por
ser uma metodologia altamente prtica, a engenharia evolui mais pela experincia do que pela
teoria. Isso signica que o histrico ainda um dos melhores meios para antecipar o surgi-
mento de problemas e conhecer os processos de ocorrncia dos mesmos. Mesmo assim outros
mtodos foram desenvolvidos ao longo da curta estria do software. Um deles, desenvolvido
pela IBM, chama-se Processo de Preveno de Defeitos e consiste em quatro etapas a saber
(KOSCIANSKI; SOARES, 2007):
Anlise Causal Sistemtica;
Apoio pela gerncia equipe de ao;
Reunies de Partida;
Ferramentas e Bases de Dados.
A Anlise Causal procura rastrear o surgimento de erros e encontrar solues padroni-
zadas para eles. J a Equipe de Ao visa garantir que todas as melhorias e correes foram
efetuadas. A metodologia se serve ainda das Reunies de Partida esclarecem, ao incio de uma
nova fase do projeto, o escopo e objetivo dessa mesma fase. Por m h a utilizao de Ferra-
mentas e Bases de Dados que objetiva aumentar o arcabouo histrico da correo de erros a
m de ser reutilizado.
EXPLICAR MAIS SOBRE ISSO.
A metodologia PPD produziu uma taxa mdia de reduo de defeitos equivalente a 50%
(KOSCIANSKI; SOARES, 2007). A IBM tambm desenvolveu no incio da dcada de 90 uma
outra metodolia denominada Classicao Ortogonal de Defeitos (COD), que feita mediante
considerao de diversos aspectos como impacto do defeito, idade do defeito, tipo do defeito
ou fonte do defeito.
5.2 Testes de Software
A anlise e identicao dos defeitos dependem de um fato crucial, que o surgimento
do defeito e sua consequente visibilidade. Alguns defeitos podem ser difceis de serem identi-
cados. Por isso faz-se necessrio a criao sistemtica de condies para o aparecimento de
defeitos, o que denomina-se Teste de Software. Em outras palavras, o teste a vericao de
que o software faz o que deveria fazer e de que no faz o que deveria no fazer. A importncia
do teste vem sobretudo do custo que para reparar o software tardiamente, custo que, alis,
representava 15% do oramento total da produo de software na dcada de 80 (RIOS; FILHO,
2006).
Como qualquer etapa da produo de software, os testes possuem custos e alocam recur-
sos. E como a taxa de defeitos diminui a medida que so procurados e corrigidos, torna-se cada
41
vez mais dispendioso continuar com a testagem. No se pretende armar com isso a necessi-
dade de interrupo da testagem, mas deve-se julgar se a continuao da testagem prudente
ou no. Por exemplo, em casos de softwares comerciais, no h necessidade de aumentar os
custos do produto procurando por erros raros e que no prejudicam o funcionamento global do
produto. Por outro lado no caso de sistemas mdicos como o Therac-25, o mau funcionamento
do software custou vidas humanas, o que justicaria uma necessidade do aumento do nmero
de testes, ainda que tal procedimento causasse um aumento signicativo nos custos (KOSCI-
ANSKI; SOARES, 2007).
Mesmo que em certos casos no se faa questo de evitar custos, preciso admitir que
os recursos de testes (ferramentas, tempo, pessoas e dinheiro) so escassos. Por isso que os
testes , ainda que indispensveis, tambm deve ser medidos quanto a sua ecincia e eccia,
quer dizer, um teste deve encontrar o maior ndice de erros possveis com a menor quantidade
de recursos possvel (KOSCIANSKI; SOARES, 2007).
Assim que, atravs do surgimento das metodologias geis de desenvolvimento, cou
evidenciada a necessidade de planejar os testes antes da codicao do software. Programado-
res orientados pela metodologia Extreme Programming (XP), escrevem os testes com os seus
diversos objetivos e s ento comeam a programar. Um fato interessante que essa metodo-
logia sugere a constante testagem do cdigo para assegurar qualidade ao projeto global atravs
da qualidade de suas partes.
5.2.1 Planejamento de Testes
Conforme dito anteriormente, os testes e sua alocao de recursos devem ser idealmente
enumerados antes da execuo do projeto, na fase de planejamento. O plano facilita a comu-
nicao entre os envolvidos e a visualizao do escopo do projeto (DINSMORE; CABANIS-
BREWIN, 2006). por isso que a IEEE criou um padro para plano de testes. Apresentemos
um resumo (KOSCIANSKI; SOARES, 2007).
Propsito: identica o escopo e objetivo do projeto;
Identicador: associa um identicador ao plano de testes;
Introduo: resume os itens a serem testados;
Itens: identica os itens a serem testados;
Funcionalidades: discrimina as funcionalidades que sero testadas;
Abordagem: identica as atividades, tcnicas e ferramentas envolvidas nos testes;
Critrios de Aceite: especica os critrios de aceite para cada item;
Suspenso: especica os critrios de suspenso da atividade de teste;
Produtos: identica os documentos produzidos;
Tarefas de Teste: identica as atividades envolvidas nos testes;
Ambiente: identica as necessidades do ambiente;
42
Responsabilidades: identica os responsveis pelas fases do projeto;
Treinamento: identica a necessidade e opes de treinamento;
Cronograma: identica atividades e prazos;
Riscos: identica os maiores riscos;
Aprovaes: identica os responsveis pela aprovao do plano.
5.3 Casos de teste
Toda etapa de produo pode ser considerada como um processo de mudana em que
so inseridos inputs e so obtidos outputs (CHAMBERS; JONHSTON; SLACK, 2009). No
s o processo de produo do software se encaixa nessa denio como o prprio software,
se colocado sob a perspectiva de ferramenta para a na etapa de produo de algum insumo. O
comrcio de um produto pode ter como etapa a insero de dados em um sistema de informtica
que vai calcular o valor da compra, emitir notal scal dentre outras atividades. Atravs desse
conceito possvel interpretar que um defeito de software pode ser denido como um output
inesperado e/ou indesejado a partir de um input conhecido.
A partir disso observa-se a necessidade de testar todos ou quase todos os inputs poss-
veis. Cada conjunto de inputs chamado de Caso de Teste. Por outro lado, devido a quantidade
exorbitante de possibilidades, os testes no podem revelar a ausncia total de erros, uma impos-
sibilidade tcnica, portanto.
1
2 def c a l c u l a d o r a ( c a r a c t e r e ) :
3 # p r o c e s s a c a r a c t e r e
Cdigo 5.1: Funo com uma entrada
A funo acima recebe como um input um caractere. Admite, portanto 256 entradas
diferentes, o que nos obriga a realizar 256 testes se quisermos garantir a ausncia total de erros
e testar todas as entradas. Por outro lado, observemos a funo abaixo:
1
2 def c a l c u l a d o r a ( c a r a c t e r e , i n t e i r o ) :
3 # p r o c e s s a c a r a c t e r e
Cdigo 5.2: Funo com duas entradas
Esta funo aceita dois parmetros de entrada o que aumenta a possibilidade de entradas
at a quantidade de 256x2
40
. Um nmero to grande de possibilidades pode exigir mais de 240
horas de testes automatizados. Isso sem mencionar o fato de que estamos ignorando que a lin-
guagem Python no fortemente tipada, o que acarreta que alm de inteiros e caracteres, ambas
as variveis de entrada da funo podem receber qualquer tipo de dado, incluindo strings, boo-
leanos e doubles. Como consequncia, no possvel testar todas as possibilidades, devendo-se
escolher as possibilidades mais signicativas e propensas a defeitos.
43
5.3.1 Fatores Psquicos
O objetivo dos testes de software salientar erros de cdigo. Ora, erros de cdigo
so produzidos pelo programador. Um programador vaidoso ter diculdades em admitir seu
prprio erro e sobretudo em corrigi-lo. Esse um motivo pelo qual muitos programadores no
testam o prprio cdigo ou ao menos no gostam muito da ideia de testa-los. A essa resistncia
ao cumprimento da tarefa, denominamos Dissonncia Cognitiva (KOSCIANSKI; SOARES,
2007).
Uma outra razo para que o programador no teste o prprio cdigo que atarracado a
lgica da sua rotina, ele no conseguir criar um teste que extrapole sua prpria lgica. Se isso
fosse possvel, provavelmente o programador poderia perceber o erro antes de test-lo.
5.3.2 Coberturas de Testes
Como mencionado acima, os testes no podem cobrir todas as possibilidades, mas po-
dem cobrir as possibilidades mais importantes. Para tal necessrio ter em conta uma faixa
de possibilidades. Por isso foi criado o que chamamos de Anlise de Mutantes. Consideramos
para tal, diversas verses defeituosas do software em que os defeitos so intencionalmente cri-
ados, como excluso de linhas, omisso de vericaes entre outras coisas. As verses com
defeitos so chamadas mutantes, por isso que o mtodo chamado de Anlise de Mutantes.
Os defeitos devem ser introduzidos aleatoriamente.
5.4 Tipos de Teste
Barry Boehm foi um dos pioneiros em Engenharia de Software e segundo ele h dois ti-
pos de testes que podemser feitos mediante entrada e vericao da sada: Testes de Caixa-preta
e Testes de Caixa-branca. Os Testes de Caixa-preta consistem em analisar se as sadas obtidas
atravs do sistema condizem com a especicaes do projeto. J os Testes de Caixa-branca con-
sistem em identicar possibilidades de testes mediante anlise do cdigo (SOMMERVILLE,
2011). O nome de caixa-preta deriva do fato de que o sistema testando ignorando-se seu
funcionamento interno. Por outro lado, o nome caixa-branca quer indicar que o funcionamento
interno do programa conhecido pelo teste (KOSCIANSKI; SOARES, 2007).
Tambm h o Teste de Estresse, que consiste em levar o software a condies mximas
de uso e vericar os defeitos decorrentes dessa situao. Um software de rede do lado do
servidor pode ter seu comportamento testando quando um nmero alto de requisies feito
pelos clientes.
Existe ainda o Teste de Integrao, que na verdade buscar por ocorrncia de defeitos
devido a m integrao entre os componentes de software. Em geral, os componentes so antes
testados separadamente para depois serem testados em conjunto. Alm desses dois testes, so
comuns os testes de aceitao e de orientao a objeto. O teste de aceitao tem por objetivo
buscar erros junto ao cliente par avaliar o uso e a qualidade externa. J o teste de orientao a
objeto procura por defeitos provenientes dos inmeros estados que os objetos podem assumir.
Vejamos cada um separadamente.
44
5.4.1 Caixa-preta e Caixa-branca
Na realidade as cores atribudas aos nomes dos respectivos testes so uma adaptao dos
termos originais. Emingls os termos respectivamente corretos para Caixa-preta e Caixa-branca
seriam Black-box e Clear-box, o que quer caria melhor adaptado como Caixa-escura e Caixa-
transparente, j que no teste de Caixa-preta abstramos o funcionamento interno do sistema e no
teste de Caixa-branca, o funcionamento interno do sistema fosse totalmente visvel, como um
cap transparente de carro que revelasse o funcionamento do motor. Nas guras abaixo, estado
quer dizer algum modo observvel do comportamento do sistema (PRESSMAN, 2010).
Figura 5.1: Modelo de teste em Caixa-preta.
Na gura acima, observe que mecanismo pelo qual o dado manipulado permanece
obscuro, ao contrrio do que mostra a gura a seguir.
Figura 5.2: Modelo de teste em Caixa-branca.
Todo o mecanismo da manipulao do dado transparante ao teste. Certamente que
possvel testar de acordo com diversos graus de granularidade. Porm esse mtodo bem mais
usual em paradigmas procedurais, uma vez que a orientao ao objeto implementa abstraes
45
atravs do encapsulamento de dados, o que seria mais condizente com tcnicas de Caixa-preta
sob certo aspecto (PRESSMAN, 2010).
5.4.2 Teste de Estresse
Como dito anteriormente, possvel submeter softwares a casos extremos de funciona-
mento para vericar o surgimento de defeitos. bastante utilizado em sistemas de transmisso
de dados (SOMMERVILLE, 2011). Esse tipo de teste visa dois objetivos:
Causar defeitos ao sistema, que detectados podero ser corrigidos;
Testar o comportamento das falhas do sistema.
Deste modo h sistemas que preferencialmente utilizam o Teste de Estresse. Sistemas
distribudos, aplicaes industriais e jogos de computador. Todos esses sistemas precisam ser
submetidos a estresse para que sua taxa de aceitao seja maior no mercado. Certos tipos de
estresse so particularmente oriundos devido as limitaes fsicas da mquinha, uma certa quan-
tidade de memria RAM, por exemplo. Uma alternativa de testagem para esse tipo de software
montar diversas conguraes de computador a m de identicar a quantidade mnima de
memria em que o sistema consegue operar sem defeitos. Por outro lado, tal alternativa muito
dispendiosa, por isso que existem ferramentas capazes de reduzir articialmente o desempenho
do sistema a m de que se proceda o teste menos dispendiosamente (KOSCIANSKI; SOARES,
2007).
5.4.3 Testes de Integrao
"Teste de integrao uma tcnica sistemtica para construo de arquitetura de soft-
ware enquanto se produz testes para descobrir erros relacionados a interface entre os compo-
nentes."(PRESSMAN, 2010) H diversas maneiras de testar a integrao. Uma delas a pers-
pectiva Top-down incremental. Nesta abordagem o teste feito aos poucos a partir do corao
do sistema, a cada integrao de seus componentes subordinados.
A abordagem Top-down feita em cinco passos, a saber:
Passo 1: O mdulo de controle usado como test-driver e os seus subordinados diretos
so inseridos e testados;
Passo 2: Os mdulos subordinados diretamente ao mdulo de controle so adicionados e
testados ou todos simultaneamente ou um a um;
Passo 3: Testes so conduzidos a medida que cada componente inserido;
Passo 4: Outro mdulo adicionado;
Passo 5: feito teste de reverso.
46
Figura 5.3: Modelo de Teste de Integrao Top-down.
Apesar de relativamente simples, a abordagem Top-down pode envolver certos proble-
mas logsticos. O mais comum dentre eles o fato de certos mdulos hierarquicamente mais
altos do sistema podem necessitar de mdulos hierarquicamente baixos para a execuo de to-
das as funcionalidades. Desta maneira o teste pode se tornar complicado caso a hierarquia do
sistema seja muito verticalizada. Tambm possvel o Teste de Integrao Bottom-up. Nesta
abordagem, so testados os mdulos das hierarquias mais inferiores e a integrao de cada com-
ponente feita incrementalmente at o topo da hierarquia.
Figura 5.4: Modelo de Teste de Integrao Bottom-up.
A abordagem Bottom-up feita em quatro passos, a seguir:
Passo 1: Os mdulos de nvel hierrquico mais baixo so agrupados em clusters;
Passo 2: Um driver escrito para coordenar as entradas e sadas entre os clusters;
Passo 3: Teste do cluster;
47
Passo 4: Remove-se o driver e o cluster acoplado ao mdulo hierrquicamente superior.
5.4.4 Teste Orientado a Objetos
O paradigma orientado a objetos causou uma mudana profunda na maneira de projetar
e pensar software. Consequentemente os testes para esse tipo de paradigma deveriam tambm
sofrer uma mudana de ao. Em um sistema orientado a objetos, cada objeto e sua respectiva
instncia possuem dados encapsulados e mtodos internos de mudana de estado. Por isso que,
sob certo aspeto, o teste orientado a objetos funciona como um teste caixa-preta, j que se ignora
o funcionamento interno dos objetos. Por outro lado, em algum momento o mecanismo interno
das classes dever ser testado para assegurar o funcionamento adequado do sistema.
Alm disso, os objetos se relacionam uns com os outros, nos obrigando a encarar a
testagem da integrao entre eles, ainda que talvez no consideremos sua posio hierrquica.
Por exemplo, a classe carro pode depender da classe pneu para executar o mtodo correr. Deste
modo ainda que todo funcionamento da classe carro esteja assegurado isoladamente, a medida
que se aciona o mtodo correr isolando sua dependncia da classe pneu, o estado do carro pode
no mudar, aparentando um erro. Certamente o teste orientado a objeto deve ser muito mais
cuidadoso. No se pode mais imaginar o sistema como uma hierarquia de processos, mas como
um relacionamento de classes totalmente integrado e coeso aonde as abordagens top-down e
bottom-up no fazem mais sentido algum (PRESSMAN, 2010).
H duas abordagens possveis para testar a integrao em sistemas orientados a objeto.
Uma delas consiste em agrupar um conjunto de classes no que chamamos de threads, algo
semelhante aos clusters da abordagem bottom-up, e test-las nesse conjunto. A outra consiste
em comear os testes pelas classes que necessitem de poucas classes para seu funcionamento e
prosseguir testando classes cada vez mais dependentes.
5.4.5 Teste de Validao
Todos os tipos de testes anteriormente mencionados dizem respeito a etapa de veri-
cao do software. Mas tambm preciso valid-lo, isto assegurar que o software oferece
as funcionalidades para resolver o problema para o qual foi proposto. Ningum melhor que o
cliente pode informar se o software resolve os problemas que ele mesmo desejava resolver ao
encomendar o software. Utilizando as palavras de Pressman, a validao do software atingida
atravs de sries de testes que demonstram conformidade com os requerimentos (PRESSMAN,
2010).
Aps o teste de validao duas situaes so possveis: ou o produto atende aos requi-
sitos ou no. Nas metodolodias clssicas de desenvolvimento, aps uma inconformidade aos
requisitos era de diclima correo, pois os testes de validao eram realizados ao nal da pro-
duo. Contudo com as modernas metodologias geis o software construdo junto ao cliente,
implicando em testes de validao constante, o que permite a alterao de qualquer requisito
durante a produo (ASTELS; MILLER; NOVAK, 2002).
48
5.4.6 Test-driven Develpment
A medida que o sistema just-in-time foi incorporado produo de software, novas
maneiras de testar software surgiram. Uma dessas maneiras chamada "Test-driven Develop-
ment", que se dene por um meio de se desenvolver software baseando-se em testes para tal.
Diversos benefcios so apontados pelos tericos dessas teorias, dentre eles podemos citar: sa-
tisfao do usurio, desenvolvimento sustentvel, aprendizado constante e integrao da equipe
(BECK, 2003). Em se tratando de TDD, deve-se sempre haver preocupao em desenvolver um
cdigo limpo que para ser funcional precisa obedecer a duas regras:
Escrever novo cdigo apenas em caso de erro apontado por teste e
Eliminar duplicao.
Embora simples, as duas regras acima implicam em uma srie de desdobramentos. Se
o cdigo novo deve ser escrito apenas em caso de erro apontado por teste, signica que o teste
deve ser escrito antes da escrita do cdigo. Alm disso, nenhuma deciso poder ser tomada
antes de consultar o feedback oferecido pelo teste. Uma outra implicao que o prprio
programador do cdigo deve ser responsvel pela escrita do teste, j que o cdigo tem que ser
constantemente testado. As rpidas respostas a mudanas tambm so uma consequncia deste
modelo de desenvolvimento alm de produzir um software altamente coeso e pouco acoplado.
As tarefas do programador tambm devem ser orientadas pelas regras acima e so cons-
titudas pelas etapas a seguir:
Vermelho - Escrever um teste que no funciona;
Verde - Fazer o teste funcionar rapidamente;
Refatorao - Eliminar toda duplicao criada pelo processo anterior.
Esse tipo de procedimento na programao diminui signicativamente a densidade de
erros alm de reduzir o nmero de surpresas que seriam causadas pela utilizao dos modelos
convencionais de testes.
1
3 i mpor t u n i t t e s t
4 from s h o u l d _ d s l i mpor t s houl d
5 from f i g u r a s _ g e o me t r i c a s i mpor t Quadrado
6
7 c l a s s Te s t a r _qua dr a do ( u n i t t e s t . Tes t Cas e ) :
8 def t e s t _ p o s s u i _ l a d o ( s e l f ) :
9 quadr ado = Quadrado ( 2 )
10 quadr ado . c o n s u l t a _ l a d o ( ) | s houl d | e qu a l _ t o ( 2 )
11
12 def t e s t _ a l t e r a _ d a d o ( s e l f ) :
14 quadr ado . a l t e r a _ l a d o ( 5 )
15 quadr ado . c o n s u l t a _ l a d o ( ) | s houl d | e qu a l _ t o ( 5 )
16
49
17 def t e s t _ o b t e m_ a r e a ( s e l f ) :
19 quadr ado . obt em_ar ea ( ) | s houl d | e qu a l _ t o ( 4 )
20
21
22 i f __name__==" __mai n__ " :
23 u n i t t e s t . main ( )
Cdigo 5.3: Exemplo de teste em Python oferecido pelo pacote Unittest.
6 TESTES COM O SONAR
6.1 O Sonar
A integrao contnua uma realidade em diversos segmentos da indstria de software.
Muitos outros prossionais, como editores de revistas e livros, tambm se apoderam dessa
tcnica, que permite atualizao constante do produto em desenvolvimento.
Para cada tipo de produto, um tipo de anlise de qualidade. Por isso para o software so
necessrias anlises especcas de sua qualidade. Estas devem estar de acordo com as normas
estabelecidas pelos organismos internacionais e pelas prticas mais modernas de desenvolvi-
mento.
Assim que para analisar a qualidade de um software atualizado a todo momento por
meio da integrao contnua, outros tipos de ferramentas sero necessrios. Uma dessas ferra-
mentas o Sonar.
O Sonar capaz de encontrar cdigo duplicado, reportar grcos de complexidade,
monitorar atualizao de verses, bem como encontrar bugs dos mais variados tipos. Trata-
se, portanto, de uma ferramenta bastante completa e complexa. Por isso grandes empresas a
tem utilizado, como Siemens e Ebay.
A ferramenta constituda por 3 partes (SONAR SOURCE, 2013):
Um banco de dados;
Um Servidor;
Diversos clientes que rodam os testes.
O banco de dados serve para armazenar as conguraes e os dados das anlises. J os
clientes rodam os diversos tipos de teste que a ferramente oferece.
6.1.1 Instalando o Sonar
O primeiro passo para se instalar o Sonar consiste em obter a plataforma Java e instal-la
no servidor que executar o Sonar. Tal ferramenta escrita em Java, sendo essencial , por isso,
a instalao de tal plataforma.
No Linux Ubuntu, so necessrios os seguintes passos para instalar-se o Sonar:
Logar como super user;
51
Editar o arquivo /etc/apt/sources.list e adicionar o valor
deb http://downloads.sourceforge.net/project/sonar-pkg/deb binary/;
Digitar sudo apt-get update e enter;
Digitar sudo apt-get install sonar;
Como super user editar o arquivo /opt/sonar/conf/sonar.properties;
Retirar o comentrio das linhas referentes ao contexto, porta e host do Sonar;
Determinar o localhost como 9000;
Logar no MySQL como - u root -p;
CREATE DATABASE IF NOT EXISTS sonar
CHARACTER SET utf8 COLLATE utf8_general_ci;
Finalmente adicionar o endereo do sonar-runner ao bashrc;
Fonte: Sonar Source (2013)
6.1.2 Instalando plugin para Python
Fazer o download do plugin para Python em:
repository.codehaus.org/org/codehaus/sonar-plugins/python/sonar-python-plugin/1.1/sonar-
python-plugin-1.1.jar ;
Logar como super user;
Colocar o arquivo jar na pasta /opt/sonar/extensions/plugins;
6.2 Testes com o Sonar
O primeiro passo para executar um teste iniciar o servidor. Para isso basta digitar
/etc/init.d/sonar start e o servidor ser inicializado imediatamente. Conforme as alteraes exe-
cutadas, ele rodar na porta 9000 como localhost, assim poderemos acess-lo atravs de um
navegador web. necessrio esperar algum tempo aps o comando para poder acessar o ser-
vidor, dependendo da velocidade da mquina. Tambm de se observar que um projeto em
produo no ter um servidor na mquina local, mas sim em rede, de forma que o endereo
dever ser corretamente discriminado no arquivo sonar.properties.
Osegundo passo consiste emcolocar no diretrio do projeto umarquivo denominado so-
nar_project.properties, facilmente encontrado no endereo https://github.com/SonarSource/sonar-
examples/blob/master/projects/languages/python/python-sonar-runner/sonar-project.properties .
Tal arquivo tem a nalidade de conduzir a anlise dentro do projeto. Salienta-se a necessidade
de alterar o valor sonar.sources de acordo com o local em que se encontra instalado o Sonar.
O terceiro passo consiste em executar a anlise atravs do sonar-runner. Para tal basta
entrar na pasta do projeto e digitar sonar-runner no console. Imediatamente a anlise comear
a ser feita.
52
Aps todos esses passos, ser possvel observar um relatrio grco em uma pgina web
encontrada em localhost. A tela inicial ser a seguinte:
Figura 6.1: Tela inicial.
No alto do canto direito da tela, encontra-se a lista de todos os projetos analisados. Para
exemplicar, o seguinte cdigo em Python foi submetido anlise:
1 from pe s s oa s i mpor t Pe s s oa s
2 c l a s s Al unos ( Pe s s oa s ) :
3 numero = None
4 def s et _numer o ( s e l f , numero )
5 s e l f . numero = numero
Cdigo 6.1: Alunos.py
Ao clicar no nome do projeto analisado, um relatrio ser exibido contendo os detalhes
da anlise. esquerda observa-se a data da anlise, a verso do projeto e o tipo de linguagem
utilizada. direita esto todas as violaes separadas em cinco nveis de gravidade. No caso
de um grande projeto, os violaes sero numericamente discriminadas conforme ocorrncia
e agrupadas conforme nvel de gravidade.Isso permite uma visualizao rpida e precisa da
situao geral do projeto. No caso de haver falhas, o Sonar costuma oferecer a soluo para
correo do problema, de acordo com os princpios estabelecidos em engenharia de software.
Todas essas informaes encontram-se na tela denominada dashboard. Havero outros tipos de
relatrio, com outros tipos de informao em outras telas.
Tambm preciso observar que Alunos.py um cdigo pequeno, cuja anlise poderia
ser menos dispendiosa se feita a olho nu. Mas tratando-se de um exemplo inicial, um pequeno
cdigo mais facilmente aproveitado que um projeto complexo. Abaixo podemos observar as
informaes contidas no dashboard.
53
Figura 6.2: Relatrio da anlise de Alunos.py.
Alm disso, h uma tela especial que lista todos os detalhes do projeto. Seu nome
Time Machine. Nela possvel encontrar diversas informaes como quantidade de linhas de
cdigo, nmero de classes e mtodos, alm de medidas de complexidade e cobertura dos testes,
caso tenham sido escritos testes de unidade para o projeto.
Figura 6.3: Time Machine
Mas no somente isso compe as telas do Sonar. Ainda existem duas telas mais re-
nadas. Seus nomes: Hotspots e Reviews. A tela Hotspots mostra uma lista das regras mais
violadas, dos recursos mais violados e das linhas duplicadas. J a tela Reviews mostra a lista de
revises executadas e das violaes ainda por revisar alm de descrever o plano de ao. Ambas
as telas so demonstradas abaixo.
54
Figura 6.4: Reviews.
Figura 6.5: Hotspots.
6.3 Concluso
Todos esses recursos tornam o Sonar uma das mais brilhantes ferramentas disponveis
no mercado, com a vantagem adicional de gratuidade. A qualidade dos testes oferecidos pelo
software capaz de aumentar signicativamente a produtividade de equipes, no s devido a
velocidade de anlise, bem como pela oferta de solues e de mtricas adequadas.
7 O SUAP
7.1 SUAP
O Sistema Unicado de Administrao Pblica (SUAP) foi desenvolvido pelo IFF do
Rio Grande do Norte e tem por nalidade ser uma ferramenta para auxiliar os processos geren-
ciais e operacionais de uma empresa pblica, como uma universidade, por exemplo.
O SUAP comeou a ser implantado no IFF Campos por volta de do ano de 2010, com
o sistema biomtrico de ponto e cadastro de pessoal. Desde ento outros mdulos vm sendo
acoplados ao mdulo principal e costumizados pelo instituto.
Ele est baseado sobre o famoso framework Django, escrito em Python e que possui
cdigo aberto.
Figura 7.1: Tela de Login.
7.2 Django
Django um framework web desenvolvido em Python que facilita a criao de produtos
baseados em web, agilizando o desenvolvimento e oferecendo efeitos sosticados.
Ele est baseado no padro MVC e por isso cada mdulo est associado com trs arqui-
vos essenciais (HOLOVATY; KAPLAN-MOSS, 2009):
models.py
views.py
56
urls.py
O arquivo models.py contm a descrio da tabela do banco de dados. O arquivo vi-
ews.py contm a lgica de negcio e o arquivo urls.py determina um caminho url para uma
funo em python que chamar o contedo.
Tambm o projeto Django contm alguns arquivos essenciais para o funcionamento:
__init__.py
manage.py
settings.py
urls.py
O arquivo __init__.py necessrio apenas para que Python interprete o projeto como
um pacote, tratando-se, na verdade, de um arquivo vazio que raramente ser editado. J o ar-
quivo manage.py permite interao com o projeto de diversas maneiras e normalmente no ser
editado. O arquivo settings.py contm todas as conguraes do projeto e denir o comporta-
mento do mesmo. E por m, o arquivo urls.py gere todos os endereos do projeto (HOLOVATY;
KAPLAN-MOSS, 2009).
7.3 Conhecendo o SUAP
O SUAP possui diversos mdulos de negcio.
Almoxarifado;
Recursos Humanos;
Chaves;
Oramento;
Patrimnio;
Frota;
Terminal de Ponto;
Protocolo e
Relatrio.
57
7.3.1 Almoxarifado
O mdulo de Almoxarifado contm diversos recursos para administrar certos recursos
operacionais como material de consumo e material permanente. Funciona como um controle
logstico, contendo informaes como quantidade, tipo e estoque.
Na imagem abaixo, mostra-se como adicionar empenho.
Tambm possvel adicionar, remover e modicar material de consumo. Abaixo a tela
de adio de material de consumo.
Os materiais de consumo so os materiais que tem gasto dirio dentro da empresa, como
papel, detergente e sabo. J os materiais permanentes so bens mais durveis como cadeiras,
mesas e equipamentos.
Os materiais permanentes possuem uma tela de cadastro prpria, diferente da tela de
cadastro de materiais de consumo, alm de remoo e alterao disponibilizadas pelo sistema.
7.3.2 Chaves
As chaves das salas de aula precisam ter um controle. Melhor se tal controle for auto-
matizado. Por isso o SUAP disponibiliza um mdulo especial para admnistrao das chaves de
um estabelecimento pblico. Abaixo a tela de adio de nova chave.
7.3.3 Frota
A administrao da frota j algo mais complicado que a administrao de chaves,
pois envolve no s o registro dos automveis , mas tambm dos motoristas e o consequente
relacionamento entre eles. Abaixo a adio de novo motorista.
As viaturas tambm so detalhadamente descritas. O nmero do patrimnio, a cor,
modelo, capacidade mxima, a potncia e o valor no odmetro so alguns dos valores contidos
na descrio das viaturas.
Cada viatura independente do motorista, de forma que vrios motoristas podem dirigir
vrias viaturas.
Alm disso, tambm possvel agendar uma viagem, trocas de leo e ordens de abaste-
cimento.
7.3.4 Contratos
Os contratos realizados tambm podem ser monitorados pelo sistema. Tambm poss-
vel adicionar a publicao do contrato, bem como editar e remover.
A cada contrato possvel adicionar publicaes, scais responsveis pelos mesmos,
termos aditivos e emisso de despacho. Todos esses itens podem ser editados ou removidos
pelo administrador responsvel.
58
7.3.5 Terminal de Ponto
Para que os funcionrios batam o ponto eletronicamente, todas as digitais dos funcio-
nrios so colhidas e armazenadas pelo sistema. Quando o funcionrio entrar na instituio,
bastar apenas digitar o nmero de sua matrcula e aproximar a digital do leitor.
7.3.6 Patrimnio
A aplicao Patrimnio gerencia o patrimnio da instituio, no qual so registradas as
operaes de carga, descarga e transferncias patrimoniais (DGTI/IFRN, 2013). Atravs desse
mdulo possvel gerenciar baixas, cautelas, requisies e rtulos, bem como gerar pdf dos
mesmos.
7.3.7 Protocolo
Esse mdulo responsvel pela administrao dos processos internos da instituio.
7.3.8 Recursos Humanos
O mdulo de recursos humanos responsvel pela atribuio dos funcionrios s suas
tarefas especcas.
7.3.9 Telas
Figura 7.2: Adicionar Material de Consumo.
Figura 7.3: Adicionar Material Permanente.
59
Figura 7.4: Adicionar empenho.
Figura 7.5: Adicionar Chave.
Figura 7.6: Adicionar Publicao.
60
Figura 7.7: Adicionar Motorista Temporrio.
Figura 7.8: Adicionar Viatura.
61
Figura 7.9: Adicionar Contrato.
Figura 7.10: Tela Principal do Ponto.
62
Figura 7.11: Tela de Frequncia do Ponto.
Figura 7.12: Adicionar Baixa.
Figura 7.13: Modicar processo.
63
Figura 7.14: Usuario.
Figura 7.15: Adicionar curso ou concurso.
8 ESTUDO DE CASO
Como visto anteriormente, o Sonar uma poderosa ferramenta para testes. Este captulo
indicar os passos para submeter o SUAP anlise do Sonar.
8.1 Anlise
Para proceder com a anlise do Sonar necessrio que a pasta do projeto a ser analisado
contenha um arquivo essencial com as conguraes do processo.
1 # Requi r ed met adat a
2 s ona r . pr oj e c t Ke y =suap
3 s ona r . pr oj ect Name =SUAP
4 s ona r . p r o j e c t Ve r s i o n =1. 0
5
6 # Commas e p a r a t e d pa t hs t o d i r e c t o r i e s wi t h s our c e s ( r e q u i r e d )
7 s ona r . s o u r c e s =/ home / l u c a s / Document os / suap
8
9 # Language
10 s ona r . l anguage =py
11
12 # Encodi ng of t he s our c e f i l e s
13 s ona r . s our ceEncodi ng=UTF8
Cdigo 8.1: Arquivo sonar-project.properties.
Conduzida a anlise, o Sonar retornar os resultados, que podero ser observados em
uma pgina html oferecida pelo seu servidor e encontrada em localhost:9000, se estivermos
rodando o servidor na mesma mquina.
No alto direita da pgina inicial, poderemos encontrar a lista de projetos analisados
pelo Sonar. Os ttulos correspondem congurao fornecida pelo arquivo sonar-project.properties.
No caso do SUAP: sonar.projectName=SUAP.
Figura 8.1: Lista de projetos.
65
Logo abaixo da lista de projetos encontra-se um quadro grco verde que representa o
projeto com seus mdulos representados por quadrados de tamanho proporcional ao nmero de
linhas de cdigo do mdulo.
Figura 8.2: Mdulos analisados.
As cores mais claras, em especial a amarela, indicam que tais mdulos possuem menos
qualidade de cdigo. A vermelha indica um estado crtico de erros. Clicando no nome do
mdulo, teremos a resposta do porque da falta de qualidade.
Figura 8.3: Anlise detalhada do mdulo django_evolution.
Com 191 linhas de cdigo e apenas um mtodo, certo que tal mdulo possua uma
complexidade alm da esperada, uma complexidade de 44.0 por mtodo! Por isso direita
pode-se observar o baixo valor de 45% de observncia das regras.
66
Figura 8.4: Anlise detalhada do mdulo django_evolution.
O mais curioso que o mdulo django_evolution no foi desenvolvido pela equipe do
IFRN, mas sim por uma equipe internacional de programadores. Trata-se de uma extenso para
Django que permite rastreamento de models atualizados, aplicando a mudana rapidamente ao
banco de dados (GOOGLE CODE, 2013).
O Sonar no s oferece a anlise para encontrar os defeitos bem como indica as solues
para os defeitos. Abaixo trs solues so possveis para os problemas listados. Solues no
to difceis de executar.
Figura 8.5: Drilldown: solues para os problemas.
O primeiro e mais recorrente defeito o uso excessivo de comandos "print". Na verdade,
do ponto de vista da qualidade de cdigo, sempre prefervel que um mtodo apenas execute o
comportamento da classe. Nesse caso ca-se a impresso de que o mtodo possui dois compor-
tamentos, alm do fato de a classe possuir um comportamento de imprimir mensagens na tela,
que no faz parte do seu escopo. Tal problema poderia ser resolvido com uma classe ou mtodo
especco para imprimir mensagens na tela. Ademais como se a classe executasse sozinha em
um s mtodo todo o modelo, a viso e o controle.
J o segundo aponta para um uso excessivo de condicionais aninhadas. A complexi-
dade ciclomtica aumenta com o nmero de ns de deciso. Deste modo, um uso excessivo
de condicionais aninhadas deve ser evitado. Como j dizia Sertilanges: "O gnio simpli-
ca"(SERTILANGES, 2010).
Um outro problema o problema j mencionado da funcionalidade extensa. O mdulo
possui 1 arquivo com 191 linhas de cdigo e apenas um mtodo que realiza distintas tarefas, um
problema no s de qualidade de cdigo, mas de qualidade da arquitetura. Tal software mal
desenhado e sua manuteno, que uma das caractersticas da qualidade de software, diclima.
H tambm o mdulo conexaoBD que se encontra bastante danicado. O Sonar acusa
uma taxa de 63,3% de observncia de regras. Curiosamente os erros so da mesma espcie que
67
o mdulo anterior, uso excessivo do recurso de impresso na tela. Apesar desse problema ser
facilmente reparado, a presena dele pode signicar uma instabilidade na arquitetura.
Figura 8.6: Violaes no mdulo conexaoBD.
O Sonar ainda destacou em vermelho os erros no arquivo. Neste caso, todos as impres-
ses estavam localizadas em excees.
1 def c l os e Conne c t i on ( s e l f ) :
2 t r y :
3 s e l f . c onne c t i on . c l o s e ( )
4 e xc e pt :
5 p r i n t Fal ha ao De s c one c t a r
Cdigo 8.2: Erro de qualidade ocorrido.
Na verdade, Python j possui meios de tratar esse tipo de erro com lanamentos de
excees.
1 def c l os e Conne c t i on ( s e l f ) :
2 t r y :
3 s e l f . c onne c t i on . c l o s e ( )
4 e xc e pt :
5 r a i s e e r r o # e r r o deve s e r pr e vi a me nt e d e f i n i d o
Cdigo 8.3: Correo do erro anterior.
Um outro tipo de erro ocorrido, mas em outro mdulo, a complexidade excessiva de
um mtodo. No mdulo django_evolution, o arquivo __init__.py possui uma funo que excede
em 8 o limite de 10 na mtrica de complexidade de cdigo.
1 def e v o l u t i o n ( app , cr eat ed_model s , v e r b o s i t y =1 , kwar gs ) :
Cdigo 8.4: Erro no arquivo __init__.py.
Alm desses tipos de erros encontrados, o Sonar tambm acusou a presena de outros
erros em outros mdulos. Um mdulo com nmero relativamente grande de inobservncia de
regras o mdulo django_extensions, que demonstrou mais de 80 erros. Um desses erros o
uso de mais de uma instruo na mesma linha, como se demonstrar abaixo.
1 i f not name : r e t u r n user name
Cdigo 8.5: Erro no mdulo django_extensions.
Na realidade, tal erro seria facilmente corrigido se a instruo de retorno casse na linha
abaixo da instruo condicional.
68
1 i f not name :
2 r e t u r n user name
Cdigo 8.6: Correo do mdulo django_extensions.
Tambm a complexidade de um arquivo ultrapassou o limite estipulado de 80.
Figura 8.7: Anlise detalhada do arquivo dumscript.py.
Apesar deste mdulo apresentar um nmero elevado de violaes, se trata de um dos
maiores mdulos do SUAP, sendo suas violaes diludas pela mdia.
9 CONCLUSES
9.1 Objetivos alcanados
Neste trabalho foi possvel apresentar as funcionalidades da ferramenta de qualidade
Sonar.
Com o Sonar executou-se uma bateria de testes no sistema SUAP, encontrando-se diver-
sas violaes de qualidade que em sua maioria so de fcil correo.
Foram apresentadas sucintamente as tecnologias e conceitos bsicos que envolvem o
Sonar e o SUAP, como linguagem de programao, engenharia de software e o framework web
Django.
Tambm cou descrito os meios de instalao do Sonar em sistema Linux, bem como
as principais sintaxes de Python.
Alm disso foram sugeridas diversas correes em alguns arquivos que compem os
mdulos do SUAP.
70
REFERNCIAS BIBLIOGRFICAS
A. J. SOBEY. Basis Path Testing. 1997. Disponvel em:
<http://users.csc.calpoly.edu/ jdalbey/206/Lectures/BasisPathTutorial/index.html>.
Acesso em: 11/07/2013.
ABELSON, H.; SUSSMAN, G. J.; SUSSMAN, J. Structure and Interpretation of Computer
Programs. USA: MIT Press, 1996.
ASTELS, D.; MILLER, G.; NOVAK, M. Extreme Programming - Guia Prtico. Brasil:
Editora Campus, 2002.
BECK, K. Test-Driven Development. USA: Addison-Wesley, 2003.
CHAMBERS, S.; JONHSTON, R.; SLACK, N. Administrao da produo. Brasil: Atlas,
2009.
DGTI/IFRN. Manual do SUAP. 2013. Disponvel em: <https://projetos.ifrn.edu.br/projects-
/suap-documentacao/wiki>. Acesso em: 14/07/2013.
DINSMORE, P.; CABANIS-BREWIN, J. The AMA Handbook of Project Management. USA:
AMACOM, 2006.
FILHO, W. de P. P. Engenharia de Software. Brasil: LTC Editora, 2003.
FLIP CODE. Source Documentation with Doxygen. 2012. Disponvel em: <http://www-
.ipcode.com/archives/Sourceextbackslash Documentation\ with\ Doxygen.shtml>. Acesso
em: 25/03/2013.
GARDEIL, H. D. Iniciao a Filosoa de Santo Toms de Aquino, I: Introduo, LGICA.
Brasil: Duas Cidades, 1967.
GOOGLE CODE. Django Evolution. 2013. Disponvel em: <http://code.google.com/p-
/django-evolution% -/>. Acesso em: 15/07/2013.
HAUSLER, P. A.; LINGER, R. C.; TRAMMELL, C. J. Adopting cleanroom software
engineering with a phased approach. IBM Systems Journal, p. 89109, 1994.
HOLOVATY, A.; KAPLAN-MOSS, J. The Denitive Guide to Django. USA: Apress, 2009.
ISO. ISO. 2013. Disponvel em: <www.iso.org>. Acesso em: 11/07/2013.
KOSCIANSKI, A.; SOARES, M. dos S. Qualidade de Software. Brasil: Novatec, 2007.
LUTZ, M. Learning Python. USA: OReilly Media, 2009.
PRESSMAN, R. Software Engineering: A Practitioner Aproach. USA: McGraw-Hill, 2010.
RIOS, E.; FILHO, T. M. Teste de Software. Brasil: Alta Books, 2006.
71
SERTILANGES, A. A vida intelectual. Brasil: Realizaes Ldta, 2010.
SOMMERVILLE, I. Software Engineering. USA: Addison-Wesley, 2011.
SONAR SOURCE. Installing Sonar. 2013. Disponvel em: <http://docs.codehaus.org/display-
/SONAR/Installing+SonarQube>. Acesso em: 12/07/2013.
WOMACK, J. P.; JONES, D. T.; ROOS, D. The Machine that changed the world: The story of
Lean Production. USA: Free Press, 2007.

TCC

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCC

Enviado por

Direitos autorais:

Formatos disponíveis

CURSO SUPERIOR DE TECNOLOGIA EM ANLISE E

Você também pode gostar