860 research outputs found

    Proceedings of the 3rd Workshop on Domain-Specific Language Design and Implementation (DSLDI 2015)

    Full text link
    The goal of the DSLDI workshop is to bring together researchers and practitioners interested in sharing ideas on how DSLs should be designed, implemented, supported by tools, and applied in realistic application contexts. We are both interested in discovering how already known domains such as graph processing or machine learning can be best supported by DSLs, but also in exploring new domains that could be targeted by DSLs. More generally, we are interested in building a community that can drive forward the development of modern DSLs. These informal post-proceedings contain the submitted talk abstracts to the 3rd DSLDI workshop (DSLDI'15), and a summary of the panel discussion on Language Composition

    Applications of internet technology for requirements elicitation

    Get PDF
    During the Requirements Elicitation part of a project various stakeholders need to be able to communicate their requirements to the developers, and the developers need to be able communicate their understanding back to the stakeholders. Communication between the various members of the project is the key factor during the Requirements Elicitation part of a project. Easing communications between stakeholders and developers makes the process of eliciting requirement easier, leading to better requirements specification and eventually a better product. The Requirements Elicitation Process through Internet (REPI) web site has been designed and implemented to explore this idea. The prototype version of REPI guides project members through the elicitation phase using the Software Engineering Institute\u27s framework for Requirements Elicitation. The REPI web site forces stakeholders to explicitly describe the requirements and encourage early discussion between stakeholders and developers. This decreases the likelihood of misunderstood requirements, leading to better requirements specification

    A Comparative Study of GUI Testing Approaches

    Get PDF
    A maioria das aplicações de software modernas apresentam uma Interface Gráfica de Utilizador (GUI), que torna a aplicação mais simples de usar, promovendo maior produtividade e melhor acessibilidade, e oferecendo flexibilidade na forma como os utilizadores podem executar tarefas. No entanto, devido à complexidade das GUIs, o processo de teste de GUI pode ser moroso e intensivo. Assim, automatizar o processo tanto quanto possível é indispensável para testar qualquer interface gráfica mais complexa e evoluída.Existem diferentes abordagens para testes de GUI automatizados, no entanto, a maioria delas requerer esforços manuais substanciais, outras apenas são capazes de encontrar erros específicos ou não permitem a reutilização de casos de teste após alterações de sistema ou GUI. Muitos investigadores afirmam que devem ser utilizadas diferentes técnicas/abordagens para um bom processo de teste.Uma nova abordagem baseada em modelos, denominada de Pattern-Based GUI Testing, foi implementada a fim de aumentar a sistematização, reutilização e diminuir o esforço da modelação e teste de GUIs. Baseia-se no conceito de Padrões de Teste de Interface de Utilizador (UITP), que contêm estratégias de teste genéricas para testar características recorrentes e comuns (UI Patterns) em GUIs. É apoiada pela ferramenta PBGT, que integra um ambiente de modelação e execução de testes de modo a suportar a criação de modelos de teste com base em UITPs, com recurso a uma linguagem específica de domínio (PARADIGM) para modelação da GUI.Como a abordagem é recente, é relevante submetê-la a experiências e testes sistematizados a fim de avaliar o seu bom desempenho/comportamento e compará-la com outras técnicas. Assim, este trabalho de dissertação baseia-se na avaliação e comparação da abordagem PBGT em relação a outras ferramentas e técnicas, no que diz respeito à detecção de falhas, facilidade de utilização, e aos esforços necessários para testar a aplicação.Para a realização de experiências, foram introduzidas mutações em três aplicações web diferentes - iAddressBook , TaskFreak e Tudu - de modo a abranger um maior número de casos de uso, e cada mutante foi, por sua vez, testado por cada uma das ferramentas selecionadas ou desenvolvidas e que implementam as diferentes abordagens de teste consideradas.Most of the modern software applications feature a Graphical User Interface (GUI), which turns the application easier to use, promoting higher productivity and better accessibility, and offering flexibility in how users perform tasks. However, due to GUI's complexity, the GUI testing process can be a time-consuming and intensive process. Therefore, automate the process as much as possible is indispensable to test any more evolved graphic user interface.There are some common automated GUI testing approaches, but while most of them require substantial manual efforts, others lack reusability or are only able to find specific types of errors. Many researchers state that a variety of techniques should be used.A new model-based testing approach, called Pattern- Based GUI Testing, was implemented in order to increase systematization, reusability and diminish the effort in modelling and testing. It is based on the concept of User Interface Test Patterns (UITP), which contain generic test strategies for testing common recurrent behavior (UI Patterns) on GUIs, and supported by the PBGT Tool which provides an integrated modeling and testing environment that supports the crafting of test models based on UI Test Patterns, using a GUI modeling DSL (PARADIGM).As a novel proposal, it is entirely relevant to submit it to systematized experiments and tests in order to assess its good performance/behavior and compare it with other techniques. Thus, this dissertation work mainly addresses PBGT's approach, aiming to compare it with different testing approaches/tools in what concerns to errors/fault detection, ease of use, and overall efforts required to test the application.To perform the experiments, mutations were introduced in each of three different web applications - iAddressBook, TaskFreak and Tudu - to cover a greater number of use cases, and each mutant was tested by each of the selected or developed testing tools which implement the considered approaches. Those approaches' benefits and problems are then conveniently described

    Static Analysis in Practice

    Get PDF
    Static analysis tools search software looking for defects that may cause an application to deviate from its intended behavior. These include defects that compute incorrect values, cause runtime exceptions or crashes, expose applications to security vulnerabilities, or lead to performance degradation. In an ideal world, the analysis would precisely identify all possible defects. In reality, it is not always possible to infer the intent of a software component or code fragment, and static analysis tools sometimes output spurious warnings or miss important bugs. As a result, tool makers and researchers focus on developing heuristics and techniques to improve speed and accuracy. But, in practice, speed and accuracy are not sufficient to maximize the value received by software makers using static analysis. Software engineering teams need to make static analysis an effective part of their regular process. In this dissertation, I examine the ways static analysis is used in practice by commercial and open source users. I observe that effectiveness is hampered, not only by false warnings, but also by true defects that do not affect software behavior in practice. Indeed, mature production systems are often littered with true defects that do not prevent them from functioning, mostly correctly. To understand why this occurs, observe that developers inadvertently create both important and unimportant defects when they write software, but most quality assurance activities are directed at finding the important ones. By the time the system is mature, there may still be a few consequential defects that can be found by static analysis, but they are drowned out by the many true but low impact defects that were never fixed. An exception to this rule is certain classes of subtle security, performance, or concurrency defects that are hard to detect without static analysis. Software teams can use static analysis to find defects very early in the process, when they are cheapest to fix, and in so doing increase the effectiveness of later quality assurance activities. But this effort comes with costs that must be managed to ensure static analysis is worthwhile. The cost effectiveness of static analysis also depends on the nature of the defect being sought, the nature of the application, the infrastructure supporting tools, and the policies governing its use. Through this research, I interact with real users through surveys, interviews, lab studies, and community-wide reviews, to discover their perspectives and experiences, and to understand the costs and challenges incurred when adopting static analysis tools. I also analyze the defects found in real systems and make observations about which ones are fixed, why some seemingly serious defects persist, and what considerations static analysis tools and software teams should make to increase effectiveness. Ultimately, my interaction with real users confirms that static analysis is well received and useful in practice, but the right environment is needed to maximize its return on investment
    corecore