joenio / dissertacao-ufba-2016 Goto Github PK
View Code? Open in Web Editor NEWDissertação para obtenção do título de mestre no Programa de Pós-graduação em Ciência da Computação (PGCOMP) da Universidade Federal da Bahia (UFBA)
Dissertação para obtenção do título de mestre no Programa de Pós-graduação em Ciência da Computação (PGCOMP) da Universidade Federal da Bahia (UFBA)
o capitulo 3 deixa de existir
"Precisamos de mais para o texto ter um corpo mesmo." -- paulo
desdobramento da issue #40
presentes:
pauta:
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. ???
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:
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.
feedback da banca de qualificação.
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)
Cronograma de entregas:
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:
\begin{abstract}
\textit{Background:}
...
\textit{Objective:}
...
\textit{Method:}
...
\textit{Results:}
...
\textit{Conclusions:}
...
\end{abstract}
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.
Aspectos que preciso melhorar na apresentação:
O que tá bom:
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:
Preencher o formulário do PGCOMP:
https://docs.google.com/forms/d/e/1FAIpQLSc107lh80RM5JkmX9TyHXcJEJ9h5aO8E0HIOFGnhpzNxYjcMg/viewform
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.