joenio / dissertacao-ufba-2016 Goto Github PK

o capitulo 3 deixa de existir

"Precisamos de mais para o texto ter um corpo mesmo." -- paulo

desdobramento da issue #40

presentes:

• @joenio
• @paulormm

pauta:

• encontrar projetos de referência (gold) para C/C++ e Java
• redefinição de título da dissertação

ata:

• encontrar projetos de referência (gold) para C/C++ e Java
  utilizando critérios de selecionar projetos com lançamentos frequentes e com número de classes na média dos outros projetos da mesma linguagem foi selecionado o projeto cppcheck para C/C++ e pmd para Java

• redefinição de título da dissertação
  proposta simplificar o título dando foco maior no trabalho de Meirelles, deixar de dar ênfase na caracterização das ferramentas e focar em validar a abordagem de Lanza e Meirelles no domínio de análise estática, neste sentido a proposta de título é: Um estudo dos valores das métricas de código-fonte em ferramentas de análise estática. Questão de pesquisa: Ferramentas de análise estática tem melhores métricas que outros domínios de aplicação? Contribuições: CC1. Verificar e validar duas abordagens genéricas, Meirelles e Lanza, em um domínio específico. CC2. Verificar se existem diferenças nos valores de métricas de código-fonte entre as dimensões das ferramentas de análise estática. CC3. ???

• matricular no proximo semestre 2017.1
  • periodo de matricula: 12 a 16/04/2017 (pela Internet)
• após matrícula solicitar a dilatação de prazo
  • formulário de requerimento: requerimento-1.zip

Tentar gerar uma versão para ser revisada no dia 28.07, uma sexta-feira, para termos uma reunião presencial, na UnB, em 04.08, outra sexta-feira.

Capitulo 4 > Seção 4.1.

síntese da análise dos dados, tendências.

Criar um doodle com pelo menos 3 datas e 2 opções de horário (normalmente, 9 horas ou 14 horas).

pensar questões para os capitulos de caracterizacao e medicao da manutenabilidade

(futuro = após conclusão do mestrado)

o trabalho abaixo em trabalhos futuros faz perguntas muito importantes do meu ponto de vista!

What do we need to do to make a tool useful for a developer?
Much academic research has focused on the fundamental algo-
rithmic challenges of such tools rather than their usability. We
need to study, both scientifically and anecdotally, what design
choices make tools better or worse in practice.

How can we help programmers understand the output of a static
analysis tool? We need better ways to present static analysis
results in terms of the abstractions the developer has in mind.
Just as we would like to have standard tool front-ends, can we
develop standard back-ends for presenting analysis results?

\cite{Foster2007}

última reunião #28

Escrever seção sobre análise e suas limitações. Isto não ficará pronto para a qualificação, entrará no texto da dissertação.

(segue abaixo uma série de anotações livres, colagens e trechos de artigos, ideias sobre o tema, etc)

%\section{Teoria da análise estática}

Um tema presente
em todas as abordagens da análise de programa e consequentemente da análise de
código-fonte e da análise estática de código-fonte é que elas podem fornecer
apenas resultados aproximados \cite{Landi1992}.

% The expressive power of programming languages makes
% analysis even harder. Analysis routines must be explicitly
% developed to handle coding complexities, such as loops,
% conditional control flow, arrays, different variable types,
% interprocedural function calls, and aliasing. In practice no
% tool handles all possible code constructs.
% \cite{Black2007}
%
%(falar de falso positivos / negativos)
%
%(Tools that are sound with respect to a counterexample are sometimes called
%complete in academic circles.)
%
%Existem diferentes técnicas de análise estática de código-fonte, que variam desde
%simples análises léxicas, análises de fluxo de dados até a análise de grafos de fluxo de con-
%trole. Ao apontar defeitos no código, uma ferramenta de análise estática pode ou não
%cometer erros quando analisando determinado trecho de código, dada a natureza do
%defeito ali presente (ou ausência de defeitos) e à técnica de análise empregada. Al-
%gumas técnicas são menos complexas e estão mais suscetíveis a erros do que outras
%(KRATKIEWICZ, 2005). Ainda assim, cada uma das técnicas de análise estática tem
%suas limitações (CUOQ; KIRCHNER; YAKOBOWSKI, 2012), o que justifica o uso de e
%a busca por diferentes técnicas de análise.
%
%Como definido em (BLACK et al., 2007), chama-se falso positivo, ou alarme
%falso, um trecho de código apontado como defeituoso por uma ferramenta de análise
%estática que, na verdade, não se trata de um defeito, ou seja, a ferramenta cometeu
%um erro ao apontar um trecho de código não defeituoso como defeituoso. Chama-se falso
%negativo um defeito no código fonte, que se enquadra na categoria de defeitos detectados
%pela ferramenta que analisa o código em questão, que não foi detectado pela ferramenta,
%ou seja, a ferramenta cometeu um erro ao não apontar um trecho de código defeituoso.
%Uma ferramenta ideal não cometeria erros, apontando todos os defeitos do código
%(mesmo que apenas em uma dada categoria) e nunca apontando um trecho de código
%correto como defeituoso (a ferramenta não comete falsos positivos nem falsos negativos).
%Trabalhos anteriores mostram que é impossível, mesmo em teoria, produzir tal ferramenta
%(BLACK et al., 2007) devido ao Teorema de Rice (RICE, 1953), que prova que para
%qualquer propriedade de software que não seja trivial, não existe algoritmo capaz de decidir
%se um programa qualquer possui tal propriedade, de modo que buscam-se aproximações
%para a solução de problemas ou tomadas de decisões relacionadas à análise estática. É
%possível, porém, produzir ferramentas capazes de cometer apenas um dos tipos de erro
%(falsos positivos ou falsos negativos). À análise estática que não gera falsos negativos, ou
%seja, aponta todos os defeitos no código, chamamos análise correta. À análise estática
%que não gera falsos positivos, ou seja, todos os possíveis defeitos apontados por ela são
%de fato trechos de código defeituosos, chama-se análise completa. Por fim, pode-se
%relacionar os termos com os Teoremas de Incompletude (GODEL et al., 1986), de modo
%que não é possível realizar uma análise completa e correta.

\section{Desafios da análise estática}

Principal 2: Less is More. Does this movement that
started in graphic design speak to source-code analysis?
Any programmer who has set out to write an analysis tool
confronts significant obstacles. First, simple parsing is not
as simple as it should be. For example, C++ is not LR(n)
(for any n!). Furthermore, the presence of casting, pointer
arithmetic, dynamic class loading, reflection, and the like,
complicate semantic analysis. This leads to the question
“how good a tool would I need to create for programmers to
use a ‘simple’ language?” Language design seems headed
in the opposite direction (Fortran “9x” is an excellent ex-
ample). Against an increasing need for higher precision
source-code analysis, modern languages increasingly re-
quire tools to handle only partially known behavior (in the
case of Java this is caused by features such as generics, user-
defined types, plug-in components, reflection, and dynamic
class loading). These features increase flexibility at run-
time, but compromise static analysis. In considering each
of the following research areas, consider also the role that
analysis quality should play in the language design debate.

Until alternate formalisms come into common usage,
source code will continue to be definitive in describing pro-
gram behavior. Based on the past 40 years, programming
languages can be expected to continue to incorporate new
features that complicate program semantics. Given its cen-
tral role in software engineering, source code and source-
code analysis will remain “hot topics” and thus the focus
of intense research activity into the foreseeable future. To
ensure future progress including necessary, but unforeseen
breakthroughs, it is important for future source-code anal-
ysis research to continue to investigate a wide diversity of
ideas.

The BCS SIGIST defines static analysis of source code
as the “analysis of a program carried out without executing
the program” [24]. This definition emphasizes the contrast
to dynamic analysis, where the behaviour of program is
observed while it is executed.

Static analysis is not exclusively used for finding security
problems. Applications can also be found, for instance, in
compiler optimization or improvement of general code quality.

In general, static analysis problems are undecidable [11].
Thus, no analysis can be sound and complete. This means that
a static analysis program is either unable to reliably detect all
targeted problems or is prone to false positives, i.e., it reports
findings which turn out to be wrong on closer examination. A
further discussion about the implications and necessary trade-
offs is given in [28] and [2]. In practice, most tools expose
both variants of erroneous behaviour.
Available static analysis for security programs exist in the
form of freeware [26] [25] [22], academic prototypes [5] [2]
[12] [23], company-internal tools (e.g., Microsoft’s Prefast [7]
and Prefix [13]), and commercial products (see [18] for an
overview).

Evaluation criteria
Quality of the analysis.
Implemented trade-offs between precision and scalability.
Set of known vulnerability types.
Usability of the tool.

evaluating the quality of a static analysis tool for security

\cite{Johns2011}

%A análise pode ser categorizada segundo seis dimensões básicas:
%\begin{itemize}
%\item estática versus dinâmica,
%\item sound versus unsound,
%\item segura vesus insegura,
%\item sensível ao fluxo (which values a variable may have at each program point?'') %versus insensível ao fluxo (which variables can be accessed by a code?''), %\item sensível ao contexto (different solutions are computed for different chains of callers'') versus
%insensível ao contexto (``a single solution is computed for each function, no matter who calls the function''),\item complexidade. %precision vs effort
%\end{itemize}
%Estas características da análise vão afetar o resultado gerado quanto a
%confiabiliade, completude, garantia de precisão, eficiência, performance,
%complexidade computacional, precisão da informaçao, entre outras.

ver trabalho de terceiro e usar a referência Darcy

feedback de chris em 21/06:

• a hipotese 3 exige melhorar a fundamentacao sobre complexidade estrutural

desdobramento da issue #40

continuar e finalizar issue #18

@joenio e @christinaflach : coloquei em minha agenda para revisar a versão/release 2017-05-04 (https://github.com/joenio/dissertacao-ufba-2016/releases/tag/2017-05-04) nesta sexta-feira.

Mando o feedback nesta issue.

análise exploratória para interpretar e compreender a influencia das características na manutenabilidade

feedback da banca de qualificação:

revisar metricas para incluir mais referencial teorico.

Trabalhos relacionados está no Capítulo 2 - Fundamentação teórica.

• falar sobre manutenabilidade e a relação com métricas de código-fonte (SC e CC)
• enriquecer fundamentação sobre custo de mudança

(issues relacionadas #11 #17)

feedback da banca de qualificação.

• https://scholar.google.com/citations?user=nGTsM3QAAAAJ

Capítulo 4 > Seção 4.2.

Finalizar caracterização das ferramentas e avaliar se as referências abaixo são úteis para novas dimensões na caracterização das ferramentas.

The purpose of this project is to evaluate existing source code analysis tools, according to metrics
prioritizing ease of use and “quick gains” over more efficient but more complex solutions.

Categories of software analysis
tools can be established according to various criteria. One of the most relevant and interesting
criteria is whether a process is “manual” or “automatic”. Manual software improvement processes
involve a developer or a quality analysis expert to actively evaluate the piece of software, make use
of their previously acquired knowledge to understand it and identify its shortcomings. Automatic
methods consist of a tool that performs a predetermined series of tests on the piece of software it is
given and produces a report of its analysis.

avaliou uma série de ferramentas usando metricas de qualidade externa:

Installation
Configuration
Support
Reports
Errors found
Handles projects?

\cite{Hofer2010}

feedback da banca de qualificação:

"e também estudar artigos da conferência ASE"

fazer revisão "livre" de literatura sobre métricas, definir quais irei utilizar e descrevê-las.

será preciso re-ler o TCC de Ronaldo para entender melhor como foi feito.

finalizar issue #24

Prazo final para defesa: ate 09 de outubro/2017 prazo final, pior caso

Prazo final pra entregar texto à banca: entregar pra banca 2 semanas de antecedencia (a regra é 21 dias)

• 29 de setembro (sexta) entregar o texto pra banca

Cronograma de entregas:

• 17 coleta de dados e discussao
• 24 fundamentacao
• 31 capitulo 3 (ou capitulo 4, coletar dados)
• 07 capitulo 4 (tavez precise de um capitulo novo, apois fundamentacao, definicoes minhas, parte experimental, falar do meu metodo, mostrar como fazer esse tipo de estudo caso alguem queira fazer tambem)
• 14 capitulo de introdução e conclusão
• 21 revisao geral e finalizar tudo!

Apêndice A.4.

ao menos os resultados sobre CBO que já conseguimos observar

Gerar tabela automaticamente usando longtable. Ver arquivo tab-softwares-data-table.tex

Presentes:

• Christina

• Joenio

• os objetivos especificos são um detalhamento do objetivo geral

• contribuicao esperada é resultado dos objetivos especificos

• em minha pesquisa o domínio importa (análise estática)

• importam também: custo de mudança e complexidade estrutural

• datasets sao importantes para analise

• nao vai tentar explicar pq nao esta seguindo esta tendencia, nao precisa

• como investigou, pegou valores de outras metricas para ver se tinha correlacao, etc

• posso descrever de maneira livre: "numa análise esse valor parece menor por causa disso, talvez aquilo... etc"

• definir objetivos especificos: quais sao meus objetivos,

• eh um objetivo claro que alcancei ao final com metodo de trabalho?

Próxima reunião:

• quinta (16 de fev) de manhã às 11h (ssa) ou sexta final da tarde

Apêndice A.1.

ao menos alterar a cor de fundo para algo mais claro

feedback da banca de qualificação:

"vender melhor o analizo, apresentar melhor, falar mais"

ver commit 804cc72

os dados encontrados apontam um comportamento bastante estranho para a métrica cbo calculada pelo analizo, será preciso investivar o cálculo desta métrica uma vez que Ronaldo em seu TCC também sinaliza valores suspeitos para ela:

É importante enfatizar que inicialmente a métrica de acoplamento que seria uti-
lizada seria CBO, a fim de comparação com complexidade estrutural apresentados em
trabalhos como o de Terceiro e Chavez (2009). Entretanto, foram encontrados aqui valo-
res muito discrepantes dos valores esperados, divergindo muito dos valores encontrados
por Meirelles (2013), inclusive para o sistema Android, levando então a conclusão de
que algum problema pode ter ocorrido no cálculo da ferramenta. Assim, a métrica de
acoplamento utilizada neste estudo foi a métrica ACC.

• 8 março texto final
• 15 março ir pra banca

• Reduzir o número de slides para encurtar o tempo da apresentação, no ensaio usei 50min
• OK Precisa contextualizar antes do primeiro slide, mesmo que verbalmente.
• OK Colocar REFS em alguns pontos
• Para ser coerente, colocar a descrição de como calcula LCOM4
• OK Falta um slide sobre como classificar as ferramentas, quais as dimensões, etc
• OK Melhorar o contraste pois alguns slides com muito texto estão difíceis de ler
• OK Erro de ortografia no slide "sistemas complexos"
• Não está muito claro os objetivos e contribuições do trabalho, melhorar tanto nos slides quanto na apresentação
• Não fica muito claro se vou investigar a suposição de que os parsers possuem maior complexidade
• Comparar no percential 75% e não no 90% na tabela apresentada em resultados
• Explicar bem a diferença entre ACC e CBO
• Detalhar os dados da LCOM, assim como feito para ACC e CBO
• OK Explicar o que foi feito no Analizo

Aspectos que preciso melhorar na apresentação:

• Não usar o termo "coisas do software"
• Explicar melhor sobre o porque usamos percentis, no ensaio fiquei nervoso
• Explicar revisão sistemática sem referenciar revisão estruturada

O que tá bom:

• Fundamentação teórica sobre análise estática está boa

a partir do feedback dado por chris em relação ao texto da qualificação, alterar os slides para refletir o fluxo sugerido por ela, especialmente adicionar mais conteúdo sobre motivação, contextualização do problema. além disso adicionar também:

• fórmulas indicando cálculo das métricas que eu apresentar
• fundamentar complexidade estrutural e sua métrica
• fundamentar a abordagem de análise, percentis, score de similaridade, etc...
• porque usar analizo (???)
• justificar e explicar porque média não é representativa

Preencher o formulário do PGCOMP:

https://docs.google.com/forms/d/e/1FAIpQLSc107lh80RM5JkmX9TyHXcJEJ9h5aO8E0HIOFGnhpzNxYjcMg/viewform

• ☑️ enviar email para secretaria solicitando dilitação, mesmo antes da matrícula
• ⬜ pensar questões para os capitulos de caracterizacao e medicao da manutenabilidade, mover parte do conteudo do capitulo 3 para eles
• ☑️ mover parte do capitulo 3 para introdução (objetivos, questao geral, etc)
• ⬜ o capitulo 3 deixa de existir
• ❌ próxima reunião sábado dia 25 16h (à confirmar)
• ❌ avaliar possibilidade de ir a salvador entre os dias 08 e 23 de abril, trabalhar mais próximo à chris durante aguns dias/semanas

Iniciar escrita do capítulo sobre interpretação das métricas e a relação com as características, Capítulo 5.

feedback da banca de qualificação:

descrever melhor a revisao estruturada, adicionar figuras, criterios de inclusao e exclusao.

descrever melhor como será feito e fundamentar mais.