No description available.

<p>This dissertation proposes an approach to reduce the cost of manual inspections for as large a number of false positive warnings that are being reported by Static Code Analysis (SCA) tools as much as possible using Machine Learning (ML) techniques. The proposed approach neither assume to use the particular SCA tools nor depends on the specific programming language used to write the target source code or the application. To reduce the number of false positive warnings we first evaluated a number of SCA tools in terms of software engineering metrics using a highlighted synthetic source code named the Juliet test suite. From this evaluation, we concluded that the SCA tools report plenty of false positive warnings that need a manual inspection. Then we generated a number of datasets from the source code that forced the SCA tool to generate either true positive, false positive, or false negative warnings. The datasets, then, were used to train four of ML classifiers in order to classify the collected warnings from the synthetic source code. From the experimental results of the ML classifiers, we observed that the classifier that built using the Random Forests</p> <p>(RF) technique outperformed the rest of the classifiers. Lastly, using this classifier and an instance-based transfer learning technique, we ranked a number of warnings that were aggregated from various open-source software projects. The experimental results show that the proposed approach to reduce the cost of the manual inspection of the false positive warnings outperformed the random ranking algorithm and was highly correlated with the ranked list that the optimal ranking algorithm generated.</p>

Made available in DSpace on 2014-12-17T15:48:02Z (GMT). No. of bitstreams: 1 HugoFM_DISSERT.pdf: 1847783 bytes, checksum: 58d9312a629dabdd3fe4b15c8dc44101 (MD5) Previous issue date: 2012-07-26 / The Exception Handling (EH) is a widely used mechanism for building robust systems. In Software Product Line (SPL) context it is not different. As EH mechanisms are embedded in most of mainstream programming languages (like Java, C# and C++), we can find exception signalers and handlers spread over code assets associated to common and variable SPL features. When exception signalers and handlers are added to an SPL in an unplanned way, one of the possible consequences is the generation of faulty family instances (i.e., instances on which common or variable features signal exceptions that are mistakenly caught inside the system). In this context, some questions arise: How exceptions flow between the optional and alternative features an LPS? Aiming at providing answers to these questions, this master thesis conducted an exploratory study, based on code inspection and static analysis code, whose goal was to categorize the main ways which exceptions flow in LPSs. To support the study, we developed an static analysis tool called PLEA (Product Line Exception Analyzer) that calculates the exceptional flows of LPSs, and categorize these flows according to the features associated with handlers and signalers. Preliminary results showed that some types of exceptional flows have more potential to yield failures in exceptional behavior of SLPs / O mecanismo de tratamento de exce??es ? amplamente utilizado para a constru??o de sistemas robustos. No contexto de Linhas de Produto de Software (LPSs) n?o ? diferente. Uma vez que mecanismos de tratamento de exce??es est?o embutidos nas principais linguagens de programa??o da atualidade (como Java, C# e C++), podemos encontrar sinalizadores e tratadores de exce??es espalhados entre os artefatos de c?digo associados a caracter?sticas (do ingl?s: features) opcionais e obrigat?rias de uma LPS. Quando tratadores ou sinalizadores de exce??es s?o adicionados a uma LPS de forma n?o planejada, uma das poss?veis conseq??ncias ? a gera??o de produtos falhos (i.e., produtos em que exce??es lan?adas por features vari?veis ou obrigat?rias s?o erroneamente tratadas). Neste contexto, surge a pergunta: Quais as consequ?ncias de se usar o mecanismo de tratamento de exce??es em LPSs? Com o objetivo de responder a esta pergunta, este trabalho conduz um estudo explorat?rio, baseado em inspe??o de c?digo e an?lise est?tica de c?digo, cujo objetivo foi caracterizar as principais formas em que exce??es fluem em LPSs. Para apoiar a realiza??o deste estudo desenvolvemos a PLEA (Product Line Exception Analyzer), uma ferramenta baseada em analise est?tica de c?digo que calcula os fluxos excepcionais de uma LPS e os classifica de acordo com as features associadas aos seus tratadores e sinalizadores. Resultados preliminares mostraram que alguns tipos de fluxos excepcionais tem mais potencial para originarem falhas no comportamento excepcional das LPSs

A number of logical code coverage criteria have been used throughout the years in the testing of safety-critical software. Kaminski, et al. proposed Relational Operator Replacement Global (RORG), a method to bring benefits from ROR mutation to Modified Condition / Decision Coverage (MCDC), which is widely used in the avionics industry. However, there is a lack of studies in the industry to support this method. In this thesis, we report on the results of applying RORG to avionic code, augmenting an MCDC adequate test set to satisfy RORG, evaluating its ability to find real faults in industrial software. Conclusions drawn from this thesis are: (1) Faults in relational operators in avionic code are rare, no faults were found in this study. (2) 24% of the relational operators in our study would require additional software requirements to be verified for RORG coverage. (3) 37% of the relational operators in our study were infeasible to test due to program semantics. (4) 84% of the tests added covered enumeration comparisons.

Object-oriented languages have made a shift towards incorporating functional concepts such as lambdas. Lambdas are anonymous functions that can be used within the scope of other functions. In C++ lambdas are considered difficult to use for inexperienced developers. This implies that there may be problems with lambdas in C++. However, studies about lambdas in C++ repositories are scarce, compared to other object-oriented languages such as Java. This study aims to address a knowledge gap regarding how lambdas are used by developers in C++ repositories. Furthermore, examine how developer experience and software engineering practices, such as unit testing and in-code documentation, correlates with the inclusion of lambdas. To achieve this we create a set of tools that statically analyse repositories to gather results. This study gained insight into the number of repositories utilising lambdas, their usage areas, and documentation but also how these findings compare to similar studies’ results in Java. Further, it is shown that unit testing and developer experience correlates with the usage of lambdas. / Objektorienterade språk har gjort en förskjutning mot att integrera funktionella begrepp som lambdas. Lambdas är anonyma funktioner som kan användas inom ramen för andra funktioner. I C ++ anses lambdas vara svåra att använda för oerfarna utvecklare. Detta innebär att det kan vara problem med lambdas i C ++. Emellertid är studier på lambdas i C ++ repositorier mindre vanliga jämfört med andra objektorienterade språk som Java. Denna studie syftar till att ta itu med ett kunskapsgap beträffande hur lambdas används av utvecklare i C++ repositorier. Dessutom undersöks hur utvecklarvanor och sedvänjor i programvaruutveckling, till exempel enhetstestning och dokumentation, korrelerar med inkluderingen av lambdas. För att uppnå detta skapar vi en uppsättning verktyg som statiskt analyserar repositorier för att samla resultat. Denna studie fick inblick i antalet repositorier som använder lambdas, deras användningsområden och dokumentation men också hur dessa resultat jämför sig med liknande studieresultat i Java. Vidare har det visats att enhetstestning och utvecklaren erfarenhet korrelerar med användningen av lambdas.

Security deficiencies that occur in web applications can have major consequences. PHP is a language that is often used for web applications and it places high demands on how the language is used to ensure it is safe. There are several features in PHP that should be handled with care to avoid security flaws. Static code analysis can help find vulnerabilities in code, but there are some drawbacks that can occur with static code analysis tools. One disadvantage is false positives which means that the tool reports vulnerabilities that do not exist. There are also false negatives which means the tool cannot find the vulnerability at all which can lead to a false sense of security for the user of the tool. With the help of completed test cases, three tools have been investigated in a case study to find out if the tools differ in their ability to avoid false positives and false negatives. The study also examines whether the tools' rules consider the PHP language's vulnerable functions. To answer the research question, a document collection was conducted to obtain information about the tools and various vulnerabilities. The purpose of this study is to compare the ability of static code analysis tools to find PHP code vulnerabilities. The tools that were investigated were SonarQube, Visual Code Grepper (VCG) and Exakat. The study's analysis shows that VCG found the most vulnerabilities but failed to avoid false positive vulnerabilities. Exakat had zero false positives but could not avoid false negatives to the same extent as VCG. SonarQube avoided all false positives but did not find any of the vulnerabilities tested in the test cases. According to the rules of the tools, VCG had more consideration for the risky functions found in PHP. The study's results show that the tools' ability to avoid false positives and false negatives differed and their adaptation to the PHP language's vulnerable functions. / Säkerhetsbrister som förekommer i webbapplikationer kan leda till stora konsekvenser. PHP är ett språk som ofta används för webbapplikationer och det ställer höga krav på hur språket används för att det ska vara säkert. Det finns flera funktioner i PHP som bör hanteras varsamt för att inte säkerhetsbrister ska uppstå. Statisk kodanalys kan hjälpa till med att hitta sårbarheter i kod men det finns vissa nackdelar som kan uppkomma med statiska kodanalysverktyg. En nackdel är falska positiva vilket betyder att verktyget rapporterar in sårbarheter som inte finns. Det finns också falska negativa som betyder att verktyget inte hittar sårbarheten alls vilket kan leda till en falsk trygghetskänsla för användaren av verktyget. Med hjälp av färdiga testfall så har tre verktyg utretts i en fallstudie för att ta reda på om verktygen skiljer sig i sin förmåga till att undvika falska positiva och falska negativa. Studien undersöker också om verktygens regler tar PHP-språkets sårbara funktioner i beaktning. För att kunna besvara forskningsfrågan har en dokumentsinsamling genomförts för att få information om verktygen och olika sårbarheter. Studiens syfte är att jämföra statiska kodanalysverktygs förmåga att hitta sårbarheter i PHP-kod. De verktyg som utreddes var SonarQube, Visual Code Grepper (VCG) och Exakat. Studiens analys visar att VCG hittade mest sårbarheter men lyckades inte undvika falska positiva sårbarheter. Exakat hade noll falska positiva men kunde inte undvika falska negativa i lika stor utsträckning som VCG. SonarQube undvek alla falska positiva men hittade inte någon av de sårbarheter som testades i testfallen. Enligt verktygens regler visade sig VCG ta mest hänsyn till de riskfyllda funktioner som finns i PHP. Studiens resultat visar att verktygens förmåga att undvika falska positiva och falska negativa och deras anpassning för PHP språkets sårbara funktioner skiljde sig åt.

In the aviation industry, the use of software development tools is not as easily adopted as in other industries. Due to the catastrophic consequences of software errors in airborne systems, software development processes has rigorous requirements. One of these requirements is that a code standard must be followed. Code standards are used to exclude code constructions which could result in unwanted behaviours. The process of manually ensuring a specific code standard can be costly. This process could be automated by a tool for static code analysis, however, this requires a formal qualification. This thesis evaluates the process of qualifying a tool for static code analysis in accordance with the requirements of the major aviation authorities EASA and FAA. To describe the qualification process, a literature study was conducted. To further explain how an existing tool could be put through the qualification process, a case study of the existing tool Parasoft C/C++ test was conducted. The results of the literature study show what processes must be completed in order to qualify a static code analysis tool. Importantly, the study shows that no requirements are put on the development process of the tool. This was an important takeaway as it meant that an existing tool could be qualified without any additional data from the developer of the tool. The case study of Parasoft C/C++ test showed how the tool could be configured and verified to analyze code in accordance with a small set of code rules. Furthermore, three documents including qualification data were produced showing how the qualification process should be documented in order to communicate the process to an authority. The results of the thesis do not provide the full picture of how a tool could be qualified as the software, in which the tool is used, is considerations the are specific to the software the tool is used to develop still need to be taken into consideration. The thesis does, however, provide guidance on the majority of the applicable requirements. Future research could be done to provide the complete picture of the qualification process, as well as how the process would look like for other types of tools. / Inom flygindustrin är användandet av olika programmeringsverktyg inte lika självklart som inom andra industrier. På grund av de katastrofala konsekvenser som fel i mjukvaran i ett flygplan kan resultera i finns det rigorösa krav på mjukvaruutvecklingsprocessen. Ett av dessa krav är att en viss kodstandard måste upprätthållas. Kodstandarder används för att exkludera vissa strukturer i kod som kan leda till oönskat beteende. Upprätthållandet av en viss kodstandard är en långdragen process att genomföra manuellt, och kan därför automatiseras med hjälp av ett statiskt kodanalysverktyg. För att kunna använda ett sådant verktyg behövs däremot en formell verktygskvalificering. I denna uppsats kommer kvalificeringsprocessen av ett verktyg för statisk kodanalys att evalueras enligt de krav som de två stora flygmyndigheterna EASA och FAA ställer. För att förklara processen av att kvalificera ett sådant verktyg gjordes en litteraturstudie följt av en fallstudie av det existerande verktyget Parasoft C/C++ test. Resultaten av litteraturstudien beskriver de olika processerna som måste genomföras för att kvalificera ett statiskt kodanalysverktyg. Noterbart är att resultaten visar att inga krav ställs på utvecklingsprocessen av verktyget själv. Detta betyder att ett existerande kommersiellt verktyg kan kvalificeras utan att verktygsutvecklarna själva behöver bidra med extra information. Fallstudien visade hur verktyget Parasoft C/C++ test kan konfigureras och verifieras att följa en viss kodstandard. Vidare resulterade fallstudien i utkast av de nödvändiga dokumenten som behöver produceras för att kommunicera kvalificeringsprocessen till en myndighet. De resultat som presenteras i denna uppsats är i sig inte tillräckliga för beskriva hela kvalificeringsprocessen. Ytterligare överväganden som är specifika till den mjukvaran som verktyget ska användas till att utveckla måste göras för att en komplett kvalificering ska kunna genomföras. Uppsatsen bidrar däremot med riktlinjer och vägledning av majoriteten av de processerna som behöver genomföras. Ytterligare forskning kan göras för att bidra med den kompletta bilden av verktygskvalificering av ett statiskt kodanalysverktyg, samt hur kvalificering kan göras av andra typer av verktyg.

Establishing and preserving a high level of software quality is a not a trivial task, although the benefits of succeeding with this task has been proven profitable and advantageous. An approach to mitigate the decreasing quality of a project is to track metrics and certain properties of the project, in order to view the progression of the project’s properties. This approach may be carried out by introducing continuous code inspection with the application of static code analysis. However, as the initial common opinion is that these type of tools produce a too high number of false positives, there is a need to investigate what the actual case is. This is the origin for the investigation and case study performed in this paper. The case study is performed at Ida Infront AB in Linköping, Sweden and involves interviews with developers to determine the performance of the continuous inspection platform SonarQube, in addition to examine the general opinion among developers at the company. The author executes the implementation and configuration of a continuous inspection environment to analyze a partition of the company’s product and determine what rules that are appropriate to apply in the company’s context. The results from the investigation indicate the high quality and accuracy of the tool, in addition to the advantageous functionality of continuously monitoring the code to observe trends and the progression of metrics such as cyclomatic complexity and duplicated code, with the goal of preventing the constant increase of complex and duplicated code. Combining this with features such as false positive suppression, instant analysis feedback in pull requests and the possibility to break the build given specified conditions, suggests that the implemented environment is a way to mitigate software quality difficulties. / 建立和保持高水平的软件质量可以带来经济利益等诸多好处，然而这是一项很困难的任务。其中一种防止软件项目质量下降的方法是通过跟踪项目的度量值和某些属性，来查看项目的属性的变化情况。通过引入持续的代码审查和应用静态代码分析方法可以实现这种方法。然而，在人们的印象中，这类工具往往具有较高的误检，因此需要进一步调查实际情况、研究其可行性，这是本文的初始研究目标。本文在瑞典林雪平的Ida Infront AB公司开展了案例研究，调研了该公司开发人员的意见，并通过访问开发人员，确定持续的代码审查平台SonarQube的性能。作者对持续的代码审查环境进行了配置，分析了公司的部分产品，进而确定哪些规则适用于该公司。调查结果表明该工具是高质量并且准确的，还提供了持续监测代码来观察度量值的趋势和进展等先进功能，例如通过监测环路复杂度和重复代码等度量值，来防止复杂度和重复代码的增加。通过组合误检压缩、对pull requests的瞬间分析反馈、以及分解和建立给定的条件等特征，使得所实现的环境成为一种可以降低软件质量保障难度的方式。

Une des étapes les plus cruciales dans le processus d’analyse des performances d’une application est la détection des goulets d’étranglement. Un goulet étant tout évènement qui contribue à l’allongement temps d’exécution, la détection de ses causes est importante pour les développeurs d’applications afin de comprendre les défauts de conception et de génération de code. Cependant, la détection de goulets devient un art difficile. Dans le passé, des techniques qui reposaient sur le comptage du nombre d’évènements, arrivaient facilement à trouver les goulets. Maintenant, la complexité accrue des micro-architectures modernes et l’introduction de plusieurs niveaux de parallélisme ont rendu ces techniques beaucoup moins efficaces. Par conséquent, il y a un réel besoin de réflexion sur de nouvelles approches.Notre travail porte sur le développement d’outils d’évaluation de performance des boucles de calculs issues d’applications scientifiques. Nous travaillons sur Decan, un outil d’analyse de performance qui présente une approche intéressante et prometteuse appelée l’Analyse Décrémentale. Decan repose sur l’idée d’effectuer des changements contrôlés sur les boucles du programme et de comparer la version obtenue (appelée variante) avec la version originale, permettant ainsi de détecter la présence ou pas de goulets d’étranglement.Tout d’abord, nous avons enrichi Decan avec de nouvelles variantes, que nous avons conçues, testées et validées. Ces variantes sont, par la suite, intégrées dans une analyse de performance poussée appelée l’Analyse Différentielle. Nous avons intégré l’outil et l’analyse dans une méthodologie d’analyse de performance plus globale appelée Pamda.Nous décrirons aussi les différents apports à l’outil Decan. Sont particulièrement détaillées les techniques de préservation des structures de contrôle du programme,ainsi que l’ajout du support pour les programmes parallèles.Finalement, nous effectuons une étude statistique qui permet de vérifier la possibilité d’utiliser des compteurs d’évènements, autres que le temps d’exécution, comme métriques de comparaison entre les variantes Decan / A crucial step in the process of application performance analysis is the accurate detection of program bottlenecks. A bottleneck is any event which contributes to extend the execution time. Determining their cause is important for application developpers as it enable them to detect code design and generation flaws.Bottleneck detection is becoming a difficult art. Techniques such as event counts,which succeeded to find bottlenecks easily in the past, became less efficient because of the increasing complexity of modern micro-processors, and because of the introduction of parallelism at several levels. Consequently, a real need for new analysis approaches is present in order to face these challenges.Our work focuses on performance analysis and bottleneck detection of computeintensive loops in scientific applications. We work on Decan, a performance analysis and bottleneck detection tool, which offers an interesting and promising approach called Decremental Analysis. The tool, which operates at binary level, is based on the idea of performing controlled modifications on the instructions of a loop, and comparing the new version (called variant) to the original one. The goal is to assess the cost of specific events, and thus the existence or not of bottlenecks.Our first contribution, consists of extending Decan with new variants that we designed, tested and validated. Based on these variants, we developed analysis methods which we used to characterize hot loops and find their bottlenecks. Welater, integrated the tool into a performance analysis methodology (Pamda) which coordinates several analysis tools in order to achieve a more efficient application performance analysis.Second, we introduce several improvements on the Decan tool. Techniquesdeveloped to preserve the control flow of the modified programs, allowed to use thetool on real applications instead of extracted kernels. Support for parallel programs(thread and process based) was also added. Finally, our tool primarily relying on execution time as the main concern for its analysis process, we study the opportunity of also using other hardware generated events, through a study of their stability, precision and overhead

Cílem této magisterské práce je navrhnout a implementovat IDE (integrované vývojové prostředí), které zvýší efektivitu a bezpečnost vývoje pro SIMATIC WinCC Open Architecture. Tato práce je založena na výzkumu provedeném týmem z Technické univerzity v Eindhovenu a splňuje požadavky pocházející ze SCD sekce v CERN (Evropské organizace pro jaderný výzkum). Vyvinuté IDE je postaveno na platformě Eclipse, přičemž pro syntaktickou analýzu, linkování a sémantickou analýzu kódu používá Xtext framework. IDE nabízí také podporu pro nově vytvořený programovací jazyk, který umožňuje programátorům jednoduše nadefinovat šablonu pro konfigurační soubory používané WinCC OA. Interpret tohoto nového jazyka je schopen provést syntaktickou analýzu šablony a konfiguračního souboru a rozhodnout, zdali konfigurační soubor odpovídá šabloně. Praktickým výstupem této práce je integrované vývojové prostředí, které podporuje vývoj WinCC OA aplikací v CERN a periodicky provádí analýzu kódu těchto aplikací napsaného v jazyce Control script.