Modeling pavement deterioration and predicting the pavement performance is crucial for optimum pavement network management. Currently only a few models exist that incorporate the structural capacity of the pavements into deterioration modeling. This thesis develops pavement deterioration models that take into account, along with the age of the pavement, the pavement structural condition expressed in terms of the Modified Structural Index (MSI). The research found MSI to be a significant input parameter that affects the rate of deterioration of a pavement section by using the Akaike Information Criterion (AIC). The AIC method suggests that a model that includes the MSI is at least 10^21 times more likely to be closer to the true model than a model that does not include the MSI. The developed models display the average deterioration of pavement sections for specific ages and MSI values. Virginia Department of Transportation (VDOT) annually collects pavement condition data on road sections with various lengths. Due to the nature of data collection practices, many biased measurements or influential outliers exist in this data. Upon the investigation of data quality and characteristics, the models were built based on filtered and cleansed data. Following the regression models, an empirical Bayesian approach was employed to reduce the variance between observed and predicted conditions and to deliver a more accurate prediction model. / Master of Science

Regular expressions (regexes) are a widely-used yet little-studied software component. Engineers use regexes to match domain-specific languages of strings. Unfortunately, many regex engine implementations perform these matches with worst-case polynomial or exponential time complexity in the length of the string. Because they are commonly used in user-facing contexts, super-linear regexes are a potential denial of service vector known as Regular expression Denial of Service (ReDoS). Part I gives the necessary background to understand this problem. In Part II of this dissertation, I present the first large-scale empirical studies of super-linear regex use. Guided by case studies of ReDoS issues in practice (Chapter 3), I report that the risk of ReDoS affects up to 10% of the regexes used in practice (Chapter 4), and that these findings generalize to software written in eight popular programming languages (Chapter 5). ReDoS appears to be a widespread vulnerability, motivating the consideration of defenses. In Part III I present the first systematic comparison of ReDoS defenses. Based on the necessary conditions for ReDoS, a ReDoS defense can be erected at the application level, the regex engine level, or the framework/runtime level. In my experiments I report that application-level defenses are difficult and error prone to implement (Chapter 6), that finding a compatible higher-performing regex engine is unlikely (Chapter 7), that optimizing an existing regex engine using memoization incurs (perhaps acceptable) space overheads (Chapter 8), and that incorporating resource caps into the framework or runtime is feasible but faces barriers to adoption (Chapter 9). In Part IV of this dissertation, we reflect on our findings. By leveraging empirical software engineering techniques, we have exposed the scope of potential ReDoS vulnerabilities, and given strong motivation for a solution. To assist practitioners, we have conducted a systematic evaluation of the solution space. We hope that our findings assist in the elimination of ReDoS, and more generally that we have provided a case study in the value of data-driven software engineering. / Doctor of Philosophy / Software commonly performs pattern-matching tasks on strings. For example, when validating input in a Web form, software commonly tests whether an input fits the pattern of a credit card number or an email address. Software engineers often implement such string-based pattern matching using a tool called regular expressions (regexes). Regexes permit software engineers to succinctly describe the sequences of characters that make up common "languages" like the set of valid Visa credit card numbers (16 digits, starting with a 4) or the set of valid emails (some characters, an '@', and more characters including at least one'.'). Using regexes on untrusted user input in this manner may be a dangerous decision because some regexes take a long time to evaluate. These slow regexes can be exploited by attackers in order to carry out a denial of service attack known as Regular expression Denial of Service (ReDoS). To date, ReDoS has led to outages affecting hundreds of websites and tens of thousands of users. While the risk of ReDoS is well known in theory, in this dissertation I present the first large-scale empirical studies measuring the extent to which slow regular expressions are used in practice. I found that about 10% of real regular expressions extracted from hundreds of thousands of software projects can exhibit longer-than-expected worst-case behavior in popular programming languages including JavaScript, Python, and Ruby. Motivated by these findings, I then consider a range of ReDoS solution approaches: application refactoring, regex engine replacement, regex engine optimization, and resource caps. I report that application refactoring is error-prone, and that regex engine replacement seems unlikely due to incompatibilities between regex engines. Some resource caps are more successful than others, but all resource cap approaches struggle with adoption. My novel regex engine optimizations seem the most promising approach for protecting existing regex engines, offering significant time reductions with acceptable space overheads.

The meteoric increase in the popularity of JavaScript and a large developer community has led to the emergence of a large ecosystem of third-party packages available via the Node Package Manager (NPM) repository which contains over one million published packages and witnesses a billion daily downloads. Most of the developers download these pre-compiled published packages from the NPM repository instead of building these packages from the available source code. Unfortunately, recent articles have revealed repackaging attacks to the NPM packages. To achieve such attacks the attackers primarily follow three steps – (1) download the source code of a highly depended upon NPM package, (2) inject malicious code, and (3) then publish the modified packages as either misnamed package (i.e., typo-squatting attack) or as the official package on the NPM repository using compromised maintainer credentials. These attacks highlight the need to verify the reproducibility of NPM packages. Reproducible Build is a concept that allows the verification of build artifacts for pre-compiled packages by re-building the packages using the same build environment configuration documented by the package maintainers. This motivates us to conduct an empirical study (1) to examine the reproducibility of NPM packages, (2) to assess the influence of any non-reproducible packages, and (3) to explore the reasons for non-reproducibility. Firstly, we downloaded all versions/releases of 226 most-depended upon NPM packages, and then built each version with the available source code on Github. Secondly, we applied diffoscope, a differencing tool to compare the versions we built against the version downloaded from the NPM repository. Finally, we did a systematic investigation of the reported differences. At least one version of 65 packages was found to be non-reproducible. Moreover, these non- reproducible packages have been downloaded millions of times per week which could impact a large number of users. Based on our manual inspection and static analysis, most reported differences were semantically equivalent but syntactically different. Such differences result due to non-deterministic factors in the build process. Also, we infer that semantic differences are introduced because of the shortcomings in the JavaScript uglifiers. Our research reveals challenges of verifying the reproducibility of NPM packages with existing tools, reveal the point of failures using case studies, and sheds light on future directions to develop better verification tools. / Master of Science / Software packages are distributed as pre-compiled binaries to facilitate software development. There are various package repositories for various programming languages such as NPM (JavaScript), pip (Python), and Maven (Java). Developers install these pre-compiled packages in their projects to implement certain functionality. Additionally, these package repositories allow developers to publish new packages and help the developer community to reduce the delivery time and enhance the quality of the software product. Unfortunately, recent articles have revealed an increasing number of attacks on the package repositories. Moreover, developers trust the pre-compiled binaries, which often contain malicious code. To address this challenge, we conduct our empirical investigation to analyze the reproducibility of NPM packages for the JavaScript ecosystem. Reproducible Builds is a concept that allows any individual to verify the build artifacts by replicating the build process of software packages. For instance, if the developers could verify that the build artifacts of the pre-compiled software packages available in the NPM repository are identical to the ones generated when they individually build that specific package, they could mitigate and be aware of the vulnerabilities in the software packages. The build process is usually described in configuration files such as package.json and DOCKERFILE. We chose the NPM registry for our study because of three primary reasons – (1) it is the largest package repository, (2) JavaScript is the most widely used programming language, and (3) there is no prior dataset or investigation that has been conducted by researchers. We took a two-step approach in our study – (1) dataset collection, and (2) source-code differencing for each pair of software package versions. For the dataset collection phase, we downloaded all available releases/versions of 226 popularly used NPM packages and for the code-differencing phase, we used an off-the-shelf tool called diffoscope. We revealed some interesting findings. Firstly, at least one of the 65 packages as found to be non-reproducible, and these packages have millions of downloads per week. Secondly, we found 50 package-versions to have divergent program semantics which high- lights the potential vulnerabilities in the source-code and improper build practices. Thirdly, we found that the uglification of JavaScript code introduces non-determinism in the build process. Our research sheds light on the challenges of verifying the reproducibility of NPM packages with the current state-of-the-art tools and the need to develop better verification tools in the future. To conclude, we believe that our work is a step towards realizing the reproducibility of NPM packages and making the community aware of the implications of non-reproducible build artifacts.

One of the main reasons why developers investigate code history is to search for the rationale for code commits. Existing work found that developers report that rationale is one of the most important aspects to understand code changes and that it can be quite difficult to find. While this finding strongly points out the fact that understanding the rationale for code commits is a serious problem for software engineers, no current research efforts have pursued understanding in detail what specifically developers are searching for when they search for rationale. In other words, while the rationale for code commits is informally defined as, "Why was this code implemented this way?" this question could refer to aspects of the code as disparate as, "Why was it necessary to implement this code?"; "Why is this the way in which it was implemented?"; or "Why was the code implemented at that moment?" Our goal with this study is to improve our understanding of what software developers mean when they talk about the rationale for code commits, i.e., how they "unfold" rationale. We additionally study which components of rationale developers find important, which ones they normally need to find, which ones they consider specifically difficult to find, and which ones they normally record in their own code commits. This new, detailed understanding of the components of the rationale for code commits may serve as inspiration for novel techniques to support developers in seeking and accurately recording rationale. / MS

The Earth's polar ionosphere is a highly dynamic region of the upper atmosphere, and acts as the closure of the greater magnetospheric current system. This region plays host to many electrodynamic effects that impact terrestrial systems, such as power grids, railroads, and pipelines. These effects are fundamentally related to the currents, electric fields, and conductivity present in the polar ionosphere. Understanding and predicting the electrodynamics of this region is vital to being able to determine the physical impacts on terrestrial systems and provide predictions to government and commercial entities. Empirical models play a key role in the research and forecasting of the solar wind and interplanetary magnetic field's impact on the polar ionosphere, and is an active area of development and research. Recent interest in polar ionospheric conductivity has led to a community-wide campaign to develop our understanding of this portion of the electrodynamic system. Characterizing the interactions between the solar wind and the polar ionosphere is a difficult task, as the region of interest is highly data starved in many respects. In particular, satellite based data products are scarce due to being costly and logistically difficult. Recent advancements in data sources (such as the Swarm and CHAMP satellite missions) as well as continued research into the physical relationships between solar wind and interplanetary magnetic field drivers have provided the opportunity to develop new, novel tools to study this region of interest. In this dissertation, two polar ionosphere models are described in Chapters 3 and 4, along with the original research that their construction has produced in Chapter 1. These two models are combined to provide a foundation for future research in this area, which is described in Chapter 5. / Doctor of Philosophy / The Earth is subjected to a constant bombardment of solar particles and magnetic fields, known as the solar wind. Our planet’s geomagnetic field protects the atmosphere from this bombardment, and directs the plasma from the solar wind into the magnetic poles of the earth. This plasma flows through a region of the atmosphere called the ionosphere, where its energy is then dissipated. This energy has many impacts on the surface of the planet, including driving currents in power grids and generating auroral displays. The polar ionosphere is the fundamental connection between the solar wind and the planet, and being able to predict how and where this connection occurs is vital to studying its nature. This work describes two models of the plasma properties in the polar ionosphere, and provides some description of the original research that these models have garnered.

No / Several recent empirical tests of the Capital Asset Pricing Model have been based on the conditional relationship between betas and market returns. This paper shows that this method needs reconsideration. An adjusted version of this test is presented. It is then demonstrated that the adjusted technique has similar, or lower, power to the more easily implemented CAPM test of Fama and MacBeth (1973) if returns are normally distributed.

In this dissertation, we investigate jackknife empirical likelihood methods motivated by recent statistics research and other related fields. Computational intensity of empirical likelihood can be significantly reduced by using jackknife empirical likelihood methods without losing computational accuracy and stability. We demonstrate that proposed jackknife empirical likelihood methods are able to handle several challenging and open problems in terms of elegant asymptotic properties and accurate simulation result in finite samples. These interesting problems include ROC curves with missing data, the difference of two ROC curves in two dimensional correlated data, a novel inference for the partial AUC and the difference of two quantiles with one or two samples. In addition, empirical likelihood methodology can be successfully applied to the linear transformation model using adjusted estimation equations. The comprehensive simulation studies on coverage probabilities and average lengths for those topics demonstrate the proposed jackknife empirical likelihood methods have a good performance in finite samples under various settings. Moreover, some related and attractive real problems are studied to support our conclusions. In the end, we provide an extensive discussion about some interesting and feasible ideas based on our jackknife EL procedures for future studies.

Automated software test execution is a critical part of the modern software development process, where rapid feedback on the product quality is expected. It is of high importance that impediments related to test execution automation are prevented and removed as quickly as possible. An enabling factor for all types of improvement is to understand the nature of what is to be improved. The goal with this thesis is to further the knowledge about common problems encountered by software developers using test execution automation, in order to enable improvement of test execution automation in industrial software development. The research has been performed through industrial case studies and literature reviews. The analysis of the data have primarily been performed using qualitative methods, searching for patterns, themes, and concepts in the data.  Our main findings include: (a) a comprehensive list of potential impediments reported in the published body of knowledge on test execution automation, (b) an in-depth analysis of how such impediments may affect the performance of a development team, and (c) a proposal for a qualitative model of interactions between the main groups of phenomena that contribute to the formation of impediments in a test execution automation project. In addition to this, we contribute qualitative and quantitative empirical data from our industrial case studies.  Through our results, we find that test execution automation is a commonly under-estimated activity,  not only in terms of resources but also in terms of the complexity of the work. There is a clear tendency to perform the work ad hoc, down-prioritize the automation in favor of other activities,  and ignore the long-term effects in favor of short-term gains. This is both a technical and a cultural problem that need to be managed by awareness of the problems that may arise, and also have to be solved in the long term through education and information. We conclude by proposing a theoretical model of the socio-technical system that needs to be managed to be successful with test execution automation. / Syftet med denna avhandling är att utöka den vetenskapliga kunskapen om problem som kan uppstå under användning av automatiserad testning i industriell programvaruutveckling. Utveckling av programvara består principiellt av ett antal processteg: kravbehandling, detaljerad systemkonstruktion, implementation i form av programmering, och slutligen testning som säkerställer att kvaliteten på programvaran är tillräcklig för dess tilltänkta användare. Testning representerar en stor del av tiden och kostnaden för utveckling av programvaran, och detta gör att det är attraktivt att automatisera testningen. Automatiserade tester kan bidra med många positiva effekter. Testning som utförs om och om igen, för att säkerställa att gammal funktionalitet inte slutar att fungera när ändringar görs i programvaran, kan med fördel göras automatiserat. Detta frigör kvalificerad personal till kvalificerat arbete. Automatisering kan även minska ledtiden för testningen och därmed möjliggöra snabbare leveranser till kund. Ett annat mål med testautomatisering är att vara säker på att samma tester utförs på ett likartat sätt varje gång produkten testas, så att den håller en jämn och stabil kvalitetsnivå. Automatiserad testning är dock en mer komplex och kostsam verksamhet än vad man kan tro, och problem som uppstår under dess användning kan ha stora konsekvenser. Detta gäller i ännu större utsträckning i organisationer som använder moderna utvecklingsmetoder där automatisering är grundstenen för en effektiv kvalitetskontroll. För att kunna undvika så många problem som möjligt, är det därför mycket viktigt att förstå vad som händer när man använder testautomatisering i stor skala. Denna avhandling presenterar resultat från fallstudier i svensk industri, som, kombinerat med en systematisk genomgång av befintlig forskning inom området, har utförts för att söka djupare kunskap och möjligheter till generalisering. Arbetet har varit beskrivande, och förklarande, och bygger på empirisk forskningsmetodik.  I avhandlingen bidrar vi med (a) information om de problem relaterade till automatiserad testning som vi har identifierat i de empiriska fallstudierna, (b) en diskussion av dessa problem i relation till andra studier i området, (c) en systematisk litteraturstudie som ger en översikt över relevanta publikationer i området, (d) en analys av bevisen som insamlats genom litteraturstudien, samt (e) en modell av det organisatoriska och tekniska system som måste hanteras för att man skall nå framgång med ett testautomatiseringsprojekt. Resultaten tyder på att rent tekniska problem inte utgör huvuddelen av de problem som upplevs med testautomatisering. Istället handlar det till stora delar om organisationell dynamik: hantering av förändringen det innebär att införa automatisering, planering av automatisering och dess användning, samt vilka finansiella förväntningar man har på automatiseringen. / ITS-EASY Post Graduate School for Embedded Software and Systems

Submitted by Fabio Sobreira Campos da Costa (fabio.sobreira@ufpe.br) on 2016-08-17T12:14:52Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Dissertação_AlexNery_V18 (VFinal_Biblioteca).pdf: 3946748 bytes, checksum: 139ad5265a5a9bfe6cb97a591113354a (MD5) / Made available in DSpace on 2016-08-17T12:14:54Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Dissertação_AlexNery_V18 (VFinal_Biblioteca).pdf: 3946748 bytes, checksum: 139ad5265a5a9bfe6cb97a591113354a (MD5) Previous issue date: 2015-02-27 / FACEPE / Contexto – Tem-se observado que o interesse em conduzir estudos empíricos vem aumentando na comunidade de Engenharia de Software, permitindo melhorar a qualidade das pesquisas e acelerar a adoção de novas tecnologias no mercado de software. Para fomentar pesquisas empíricas nesse contexto, é essencial entender os ambientes, diretrizes, processos, ferramentas e outros recursos disponíveis para conduzir tais estudos. Objetivo – Esta pesquisa tem o objetivo de identificar mecanismos de suporte (metodologias, framework, ferramentas, guias, processos, etc.) utilizados para planejar e conduzir estudos empíricos na comunidade de Engenharia de Software Empírica. Além disso, espera-se mapear outras evidências importantes na área, como os métodos empíricos mais utilizados e a evolução, ao longo dos anos, do uso de estratégias e mecanismos de pesquisa empírica. Método – Foi adotado o Estudo de Mapeamento Sistemático, conduzido de acordo com guias e diretrizes de Engenharia de Software Baseada em Evidências. Resultado – Foram identificados 375 mecanismos. Este trabalho fornece um catálogo com informações de todos os mecanismos e em quais estratégias empíricas são aplicados. Serão abordados os mecanismos mais utilizados para guiar os principais métodos empíricos. Este trabalho também discute outras informações relevantes da comunidade de Engenharia de Software Empírica. Observou-se que a maioria dos mecanismos utilizados como referência para guiar estudos empíricos é adotado de outras áreas científicas. Além disso, muitos estudos não aplicam estratégias empíricas e / ou não citam referências para apoiar sua pesquisa. Experimento e estudo de caso são os métodos empíricos mais aplicados. Conclusão – Esta pesquisa evidenciou que a realização de estudos empíricos na Engenharia de Software tem aumentado ao longo dos anos. No entanto, ainda há lacunas a serem preenchidas, como o desenvolvimento de novos ambientes e recursos para auxiliar atividades específicas nessa área. Portanto, um catálogo de mecanismos de suporte, onde e como foram aplicados, é um trunfo importante para a comunidade de Engenharia de Software. Tal recurso pode promover a realização de estudos empíricos, no sentido de auxiliar a escolha sobre quais estratégias e guias usar em uma pesquisa. Além disso, foram identificadas novas perspectivas e lacunas que podem orientar a definição de outras pesquisas voltadas para a melhoria e disseminação de estudos empíricos na área. / Context – It is possible to observe that empirical studies are gaining recognition in the Software Engineering research community, allowing improve quality of researches and accelerate the adoption of new technologies in the software market. In order to foster empirical research in this context, it is essential understand the environments, guidelines, process, tools, and other mechanisms available to conduct such studies. Objective – This research aims to identify support mechanisms (methodology, framework, tool, guidelines, process, etc.) used to plan and to conduct empirical studies in the Empirical Software Engineering community. In addition, it is expected to map other evidence of this area, as the most widely used empirical methods and the evolution of the use of empirical strategies and mechanisms along the years. Method – The method adopted was the Systematic Mapping Study conducted according to guidelines of Evidence-Based Software Engineering. Result - A total of 375 mechanisms were identified. This work provide a catalog with information of all the identified mechanisms and the empirical strategies in which they were used to support. And also describes the most used support mechanisms to guide the main types of empirical strategies in Software Engineering. This study also discusses relevant findings of the Empirical Software Engineering community. It was observed that the most mechanisms used as a reference to guide empirical studies are not specific to this area. Besides, many studies did not apply empirical strategies and/or did not cite any resource to support their research. Experiment and case study are the empirical strategies most applied. Conclusion – This research showed that the performance of empirical studies in Software Engineering has increased over the years. However, there are still gaps to be filled, as the development of support mechanisms to specific activities in this area. Therefore, the list of support mechanisms, where and how they were applied is an important asset to the Software Engineering community. Such asset can foster empirical studies aiding the choice regarding which strategies and mechanisms to use in a research, as well as pointing out examples where they were used, mainly to newcomers researchers. Also, were identified new perspectives and gaps that foster other research for the improvement and dissemination of empirical research in this area.

Submitted by Fabio Sobreira Campos da Costa (fabio.sobreira@ufpe.br) on 2016-08-17T12:23:47Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Dissertação_AlexNery_V18 (VFinal_Biblioteca).pdf: 3946748 bytes, checksum: 139ad5265a5a9bfe6cb97a591113354a (MD5) / Made available in DSpace on 2016-08-17T12:23:47Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Dissertação_AlexNery_V18 (VFinal_Biblioteca).pdf: 3946748 bytes, checksum: 139ad5265a5a9bfe6cb97a591113354a (MD5) Previous issue date: 2015-02-27 / FACEPE / Contexto – Tem-se observado que o interesse em conduzir estudos empíricos vem aumentando na comunidade de Engenharia de Software, permitindo melhorar a qualidade das pesquisas e acelerar a adoção de novas tecnologias no mercado de software. Para fomentar pesquisas empíricas nesse contexto, é essencial entender os ambientes, diretrizes, processos, ferramentas e outros recursos disponíveis para conduzir tais estudos. Objetivo – Esta pesquisa tem o objetivo de identificar mecanismos de suporte (metodologias, framework, ferramentas, guias, processos, etc.) utilizados para planejar e conduzir estudos empíricos na comunidade de Engenharia de Software Empírica. Além disso, espera-se mapear outras evidências importantes na área, como os métodos empíricos mais utilizados e a evolução, ao longo dos anos, do uso de estratégias e mecanismos de pesquisa empírica. Método – Foi adotado o Estudo de Mapeamento Sistemático, conduzido de acordo com guias e diretrizes de Engenharia de Software Baseada em Evidências. Resultado – Foram identificados 375 mecanismos. Este trabalho fornece um catálogo com informações de todos os mecanismos e em quais estratégias empíricas são aplicados. Serão abordados os mecanismos mais utilizados para guiar os principais métodos empíricos. Este trabalho também discute outras informações relevantes da comunidade de Engenharia de Software Empírica. Observou-se que a maioria dos mecanismos utilizados como referência para guiar estudos empíricos é adotado de outras áreas científicas. Além disso, muitos estudos não aplicam estratégias empíricas e / ou não citam referências para apoiar sua pesquisa. Experimento e estudo de caso são os métodos empíricos mais aplicados. Conclusão – Esta pesquisa evidenciou que a realização de estudos empíricos na Engenharia de Software tem aumentado ao longo dos anos. No entanto, ainda há lacunas a serem preenchidas, como o desenvolvimento de novos ambientes e recursos para auxiliar atividades específicas nessa área. Portanto, um catálogo de mecanismos de suporte, onde e como foram aplicados, é um trunfo importante para a comunidade de Engenharia de Software. Tal recurso pode promover a realização de estudos empíricos, no sentido de auxiliar a escolha sobre quais estratégias e guias usar em uma pesquisa. Além disso, foram identificadas novas perspectivas e lacunas que podem orientar a definição de outras pesquisas voltadas para a melhoria e disseminação de estudos empíricos na área. / Context – It is possible to observe that empirical studies are gaining recognition in the Software Engineering research community, allowing improve quality of researches and accelerate the adoption of new technologies in the software market. In order to foster empirical research in this context, it is essential understand the environments, guidelines, process, tools, and other mechanisms available to conduct such studies. Objective – This research aims to identify support mechanisms (methodology, framework, tool, guidelines, process, etc.) used to plan and to conduct empirical studies in the Empirical Software Engineering community. In addition, it is expected to map other evidence of this area, as the most widely used empirical methods and the evolution of the use of empirical strategies and mechanisms along the years. Method – The method adopted was the Systematic Mapping Study conducted according to guidelines of Evidence-Based Software Engineering. Result - A total of 375 mechanisms were identified. This work provide a catalog with information of all the identified mechanisms and the empirical strategies in which they were used to support. And also describes the most used support mechanisms to guide the main types of empirical strategies in Software Engineering. This study also discusses relevant findings of the Empirical Software Engineering community. It was observed that the most mechanisms used as a reference to guide empirical studies are not specific to this area. Besides, many studies did not apply empirical strategies and/or did not cite any resource to support their research. Experiment and case study are the empirical strategies most applied. Conclusion – This research showed that the performance of empirical studies in Software Engineering has increased over the years. However, there are still gaps to be filled, as the development of support mechanisms to specific activities in this area. Therefore, the list of support mechanisms, where and how they were applied is an important asset to the Software Engineering community. Such asset can foster empirical studies aiding the choice regarding which strategies and mechanisms to use in a research, as well as pointing out examples where they were used, mainly to newcomers researchers. Also, were identified new perspectives and gaps that foster other research for the improvement and dissemination of empirical research in this area.