3,138 research outputs found

    Automatic Software Repair: a Bibliography

    Get PDF
    This article presents a survey on automatic software repair. Automatic software repair consists of automatically finding a solution to software bugs without human intervention. This article considers all kinds of repairs. First, it discusses behavioral repair where test suites, contracts, models, and crashing inputs are taken as oracle. Second, it discusses state repair, also known as runtime repair or runtime recovery, with techniques such as checkpoint and restart, reconfiguration, and invariant restoration. The uniqueness of this article is that it spans the research communities that contribute to this body of knowledge: software engineering, dependability, operating systems, programming languages, and security. It provides a novel and structured overview of the diversity of bug oracles and repair operators used in the literature

    A heuristic-based approach to code-smell detection

    Get PDF
    Encapsulation and data hiding are central tenets of the object oriented paradigm. Deciding what data and behaviour to form into a class and where to draw the line between its public and private details can make the difference between a class that is an understandable, flexible and reusable abstraction and one which is not. This decision is a difficult one and may easily result in poor encapsulation which can then have serious implications for a number of system qualities. It is often hard to identify such encapsulation problems within large software systems until they cause a maintenance problem (which is usually too late) and attempting to perform such analysis manually can also be tedious and error prone. Two of the common encapsulation problems that can arise as a consequence of this decomposition process are data classes and god classes. Typically, these two problems occur together – data classes are lacking in functionality that has typically been sucked into an over-complicated and domineering god class. This paper describes the architecture of a tool which automatically detects data and god classes that has been developed as a plug-in for the Eclipse IDE. The technique has been evaluated in a controlled study on two large open source systems which compare the tool results to similar work by Marinescu, who employs a metrics-based approach to detecting such features. The study provides some valuable insights into the strengths and weaknesses of the two approache

    A methodological approach on the creation of trustful test suites for grammar error detection

    Get PDF
    Machine translation’s research has been expanding over time and so has the need to automatically detect and correct errors in texts. As such, Unbabel combines machine translation with human editors in post-edition to provide high quality translations. In order to assist post-editors in these tasks, a proprietary error detection tool called Smartcheck was developed by Unbabel to identify errors and suggest corrections. The state-of-the-art method of identifying translation errors depends on curated annotated texts (associated with error-type categories), which are fed to machine translation systems as their evaluation standard, i.e. the test suites to evaluate a system’s error detection accuracy. It is commonly assumed that evaluation sets are reliable and representative of the content the systems translate, leading to the assumption that the root problem usually relates to grammar-checking rules. However, the issue may instead lie in the quality of the evaluation set. If so, then the decisions made upon evaluation will possibly even have the opposite effect to the one intended. Thus, it is of utmost importance to have suitable datasets with representative data of the structures needed for each system, the same for Smartcheck. With this in mind, this dissertation developed and implemented a new methodology on creating reliable and revised test suites to be applied on the evaluation process of MT systems and error detection tools. Using the resulting curated test suites to evaluate proprietary systems and tools to Unbabel, it became possible to trust the conclusions and decisions made from said evaluations. This methodology accomplished robust identification of problematic error types, grammar-checking rules, and language- and/or register-specific issues, therefore allowing production measures to be adopted. With Smartcheck’s (now reliable and accurate) correction suggestions and the improvement on post-edition revision, the work presented hereafter led to an improvement on the translation quality provided to customers.O presente trabalho focou-se na avaliação do desempenho de uma ferramenta proprietária da Unbabel, para detecção automática de erros, baseada em segmentos previamente anotados pela comunidade de anotadores, o Smartcheck. Assim, foi proposta uma metodologia para criação de um corpus de teste (do inglês test suites) baseado em dados de referência com estruturas relevantes (do inglês gold data). Deste modo, tornou-se possível melhorar a qualidade das sugestões de correção de erros do Smartcheck e, consequentemente, das traduções facultadas. Para além do objetivo inicial, a nova metodologia permitiu assegurar uma avaliação rigorosa, apropriada e fundamentada relativamente às regras usadas pelo Smartcheck, para identificar possíveis erros de tradução, assim como avaliar outras ferramentas e sistemas de tradução automática da Unbabel. Recentemente, assistiu-se também a uma fusão da Lingo24 com a Unbabel e, por essa razão, os dados presentes no corpus incluem conteúdo traduzido por ambas. Como tal, o trabalho desenvolvido contribuiu inclusivamente para a recente integração da Lingo24. A Secção 2 foi dedicada à apresentação da Unbabel, na qual se referem os processos de controlo de qualidade utilizados para assegurar níveis de qualidade exigidos e se descreve pormenorizadamente a ferramenta em foco, o Smartcheck. A Secção 3 focou-se no estado da arte da Tradução Automática e em processos de controlo de qualidade, dando especial atenção a corpora de teste e à influência dos mesmos. Além disso, foi também incluída uma descrição relativa ao desenvolvimento de ferramentas automáticas de deteção e correção de erros, criadas para aperfeiçoar os textos provenientes de traduções automáticas. A metodologia criada, descrita na Secção 4, foi dividida em três partes principais: avaliação piloto relativa às regras preexistentes do Smartcheck; análise de causas de erros (do inglês root-cause analysis); e, por fim, construção de um novo corpus de teste, com dados mais recentes e corrigidos. O primeiro passo na metodologia consistiu na avaliação do desempenho da ferramenta em foco na presente tese. Para tal, foi realizada uma análise piloto na qual cada regra utilizada pelo Smartcheck foi avaliada de acordo com métricas comumente aplicadas para avaliação de sistemas de deteção de erros, como o número de verdadeiros positivos (true positives) - casos em que o sistema conseguiu corretamente identificar erros -, de falsos negativos (false negatives) - casos em que existia um erro, mas o sistema não o identificou - e de falsos positivos (false positives) - casos em que o sistema incorretamente considerou existir erros. Outras métricas utilizadas para avaliação consistiram no cálculo de Precision, Recall, e F1-score, a partir dos valores obtidos das métricas anteriormente mencionadas. Tendo terminado a avaliação piloto, concluiu-se que nem todas as regras foram passíveis de avaliação (razão pela qual se tornou impossível averiguar o desempenho individual para cada regra) e, quanto às que foram avaliadas, os resultados não foram considerados satisfatórios. Isto porque, as regras não identificavam erros existentes nas traduções e consideravam como problemáticos inúmeros segmentos gramaticalmente corretos. A segunda etapa da metodologia surgiu, então, como tentativa de identificar possíveis razões pelas quais o Smartcheck e as regras associadas demonstraram um baixo desempenho. Em vista desse objetivo, foi feita uma análise na qual foi colocada a hipótese de que as regras teriam sido avaliadas com um corpus de teste não apropriado e obsoleto, explicando assim as métricas muito baixas da avaliação piloto. Esta hipótese surgiu uma vez que foi não só considerada a possibilidade de os dados do corpus não serem representativos das traduções feitas atualmente, mas também pelo facto de as estruturas consideradas problemáticas para os sistemas de tradução serem alteradas constantemente. De modo a corroborar a hipótese colocada, o corpus foi analisado com base em variados critérios: qual o tipo de tradução dos dados - se os segmentos analisados tinham ou não sido previamente revisto por pós-editores antes da respetiva submissão; existência de segmentos duplicados ou cujo texto de partida (do inglês source text) poderia conter erros - i.e. dados ruidosos; e revisão das anotações e das severidades associadas a cada erro, de acordo com tipologias e diretrizes específicas da Unbabel - considerando o número de anotações/severidades correta e incorretamente atribuídas, assim como em falta. Uma vez finalizada a análise, concluímos que cerca de 20% dos dados correspondiam a duplicações - tanto para o registo formal como para o informal -, que entre 15-25% das anotações foram consideradas incorretas e que apenas metade das severidades foram corretamente atribuídas. Assim sendo, considerámos que seria mais vantajoso criar um novo corpus representativo e refinado, ao invés de corrigir todas as anotações incorretas do corpus previamente usado. O terceiro e último passo da metodologia consistiu na construção de um novo corpus de teste com 27 500 exemplos previamente anotados de traduções automáticas. Os procedimentos para a criação deste novo corpus incluíram: filtragem de um conjunto de traduções automáticas, com dados representativos para todas as línguas suportadas pela Unbabel; distinção entre segmentos dependentes e não dependentes de contexto (uma limitação do corpus prévio); exclusão de exemplos duplicados e de casos com textos de partida problemáticos; e, por fim, revisão por parte de linguistas e tradutores das anotações atribuídas, seguindo tipologias proprietárias. Este último procedimento foi ainda subdividido em: uma avaliação geral, de modo a garantir que as traduções transmitiam de forma coerente, fluída e apropriada a mensagem do texto de partida e que, para além disso, seguiam regras específicas para cada língua; uma avaliação focada em especificidades por cliente, de modo a assegurar diretrizes existentes; e uma revisão de severidades associadas a cada anotação. Tendo sido a metodologia dada como terminada, o corpus de teste consistia agora num conjunto de dados de confiança, capaz de avaliar sistemas de tradução automática e ferramentas como o Smartcheck de uma forma objetiva e fundamentada. Posto isto, as várias avaliações realizadas - descritas na Secção 5 - usaram os dados compreendidos no corpus como termo de comparação. A primeira avaliação teve como objetivo principal comparar os resultados obtidos na análise piloto quanto às regras do Smartcheck com os resultados de uma nova avaliação das mesmas usando o novo corpus de teste, de forma a chegar a conclusões mais fiáveis e credíveis. A partir desta, foi possível concluir não só que, contrariamente às conclusões anteriores, todas as regras são agora passíveis de avaliação, mas também que o número de casos em que o Smartcheck incorretamente identificava segmentos como problemáticos foi reduzido. A avaliação seguinte comparou anotações recorrendo a uma matriz de confusão (do inglês confusion matrix) entre previsões concedidas tanto pelo Smartcheck como pelo corpus de teste. Deste modo, foi possível identificar quais os tipos de erros mais frequentes e quais os tipos mais (e menos) problemáticos de identificar pelo sistema. Assim, o corpus de teste foi considerado como gold standard de modo a realizar uma avaliação global do Smartcheck, calculando o número total de falsos positivos (atingindo cerca de 45%), falsos negativos (com 35%) e verdadeiros positivos (aproximadamente 20%). Quanto aos verdadeiros positivos, estes foram divididos em dois tipos: segmentos corretamente identificados pelo Smartcheck como erro, mas que foram classificados incorretamente (cerca de 11%); e erros em que tanto a extensão como a classificação foram atribuídas corretamente (a rondar os 8% do número total de anotações). A terceira e última análise recorreu aos totais obtidos na avaliação anterior para calcular valores para métricas como Precision, Recall e F1-score para cada língua e para cada registo suportado. Desta forma, foi possível concluir que, quanto à primeira métrica, a média entre registos estava bastante equilibrada, mas o mesmo não se verificou em Recall nem F1-score, uma vez que o registo formal atingiu valores superiores. Para além disso, recorremos ainda ao corpus para avaliar spell checkers usados pela Unbabel e, analisando os resultados obtidos, pudemos concluir que o spell checker em uso obteve a avaliação mais baixa. Tendo isto em conta, foi decidido que seria então preferível substituí-lo pelo spell checker com a melhor avaliação, de modo a reduzir o número de erros nas traduções e assim melhorar a qualidade das mesmas. Todo o trabalho realizado pôde ser implementado em vários outros campos para além do inicialmente estabelecido, i.e. para além da avaliação sistemática da ferramenta Smartcheck. Demonstrando, deste modo, todo o impacto que uma análise bem fundamentada pode ter no processo de tomada de decisão. Isto porque, sem um corpus de teste representativo e estruturado, as avaliações feitas não seriam válidas e os resultados obtidos facilmente levariam a conclusões impróprias ou até nocivas para o desenvolvimento dos sistemas e ferramentas em questão

    Summer Institute in Biomedical Engineering, 1973

    Get PDF
    Bioengineering of medical equipment is detailed. Equipment described includes: an environmental control system for a surgical suite; surface potential mapping for an electrode system; the use of speech-modulated-white-noise to differentiate hearers and feelers among the profoundly deaf; the design of an automatic weight scale for an isolette; and an internal tibial torsion correction study. Graphs and charts are included with design specifications of this equipment

    Uncovering Bugs in Distributed Storage Systems during Testing (not in Production!)

    Get PDF
    Testing distributed systems is challenging due to multiple sources of nondeterminism. Conventional testing techniques, such as unit, integration and stress testing, are ineffective in preventing serious but subtle bugs from reaching production. Formal techniques, such as TLA+, can only verify high-level specifications of systems at the level of logic-based models, and fall short of checking the actual executable code. In this paper, we present a new methodology for testing distributed systems. Our approach applies advanced systematic testing techniques to thoroughly check that the executable code adheres to its high-level specifications, which significantly improves coverage of important system behaviors. Our methodology has been applied to three distributed storage systems in the Microsoft Azure cloud computing platform. In the process, numerous bugs were identified, reproduced, confirmed and fixed. These bugs required a subtle combination of concurrency and failures, making them extremely difficult to find with conventional testing techniques. An important advantage of our approach is that a bug is uncovered in a small setting and witnessed by a full system trace, which dramatically increases the productivity of debugging

    The space physics environment data analysis system (SPEDAS)

    Get PDF
    With the advent of the Heliophysics/Geospace System Observatory (H/GSO), a complement of multi-spacecraft missions and ground-based observatories to study the space environment, data retrieval, analysis, and visualization of space physics data can be daunting. The Space Physics Environment Data Analysis System (SPEDAS), a grass-roots software development platform (www.spedas.org), is now officially supported by NASA Heliophysics as part of its data environment infrastructure. It serves more than a dozen space missions and ground observatories and can integrate the full complement of past and upcoming space physics missions with minimal resources, following clear, simple, and well-proven guidelines. Free, modular and configurable to the needs of individual missions, it works in both command-line (ideal for experienced users) and Graphical User Interface (GUI) mode (reducing the learning curve for first-time users). Both options have “crib-sheets,” user-command sequences in ASCII format that can facilitate record-and-repeat actions, especially for complex operations and plotting. Crib-sheets enhance scientific interactions, as users can move rapidly and accurately from exchanges of technical information on data processing to efficient discussions regarding data interpretation and science. SPEDAS can readily query and ingest all International Solar Terrestrial Physics (ISTP)-compatible products from the Space Physics Data Facility (SPDF), enabling access to a vast collection of historic and current mission data. The planned incorporation of Heliophysics Application Programmer’s Interface (HAPI) standards will facilitate data ingestion from distributed datasets that adhere to these standards. Although SPEDAS is currently Interactive Data Language (IDL)-based (and interfaces to Java-based tools such as Autoplot), efforts are under-way to expand it further to work with python (first as an interface tool and potentially even receiving an under-the-hood replacement). We review the SPEDAS development history, goals, and current implementation. We explain its “modes of use” with examples geared for users and outline its technical implementation and requirements with software developers in mind. We also describe SPEDAS personnel and software management, interfaces with other organizations, resources and support structure available to the community, and future development plans.Published versio
    corecore