Inviwo -- A Visualization System with Usage Abstraction Levels

The complexity of today's visualization applications demands specific visualization systems tailored for the development of these applications. Frequently, such systems utilize levels of abstraction to improve the application development process, for instance by providing a data flow network editor. Unfortunately, these abstractions result in several issues, which need to be circumvented through an abstraction-centered system design. Often, a high level of abstraction hides low level details, which makes it difficult to directly access the underlying computing platform, which would be important to achieve an optimal performance. Therefore, we propose a layer structure developed for modern and sustainable visualization systems allowing developers to interact with all contained abstraction levels. We refer to this interaction capabilities as usage abstraction levels, since we target application developers with various levels of experience. We formulate the requirements for such a system, derive the desired architecture, and present how the concepts have been exemplary realized within the Inviwo visualization system. Furthermore, we address several specific challenges that arise during the realization of such a layered architecture, such as communication between different computing platforms, performance centered encapsulation, as well as layer-independent development by supporting cross layer documentation and debugging capabilities

A systematic approach to generate test cases based on combinations of information

Software based systems incrementally provide critical services to users. Mobile telephone systems, for example, are used in circumstances in which the malfunctioning may have disastrous consequences. During the last years, software has been incorporated in devices used in daily life, such as audio and television. The diversity of systems in which software is incorporated is increasing. Thus, the software development process has to consider a variety of speci ¯cation techniques and models, incorporating also techniques from engineering sciences. In particular, the validation and veri¯cation processes have to be adapted to these new developments. For example, the testing based solely on the software speci¯cation is incomplete. First, there is an implicit objective to verify that the program works correctly (as in the testing model of the 1957{1978, [GH88]). Myers [Mye83] says that with the aim of demonstrating that a program does not fail, we can unconsciously select data that has a low probability of exposing faults. On the other hand, if the objective is to demonstrate that a program has faults, test data will have a higher probability of revealing them. In specification-based testing we select data for which the desired behavior for the system is defined. As stated by Boris Beizer [Bei95] testing should include both clean and dirty tests. Dirty tests are designed to \break" the software; clean tests are designed to demonstrate that software executes correctly. Specifications only provide clean tests.Eje: Ingeniería de Software y Base de DatosRed de Universidades con Carreras en Informática (RedUNCI

A systematic approach to generate test cases based on combinations of information

Software based systems incrementally provide critical services to users. Mobile telephone systems, for example, are used in circumstances in which the malfunctioning may have disastrous consequences. During the last years, software has been incorporated in devices used in daily life, such as audio and television. The diversity of systems in which software is incorporated is increasing. Thus, the software development process has to consider a variety of speci ¯cation techniques and models, incorporating also techniques from engineering sciences. In particular, the validation and veri¯cation processes have to be adapted to these new developments. For example, the testing based solely on the software speci¯cation is incomplete. First, there is an implicit objective to verify that the program works correctly (as in the testing model of the 1957{1978, [GH88]). Myers [Mye83] says that with the aim of demonstrating that a program does not fail, we can unconsciously select data that has a low probability of exposing faults. On the other hand, if the objective is to demonstrate that a program has faults, test data will have a higher probability of revealing them. In specification-based testing we select data for which the desired behavior for the system is defined. As stated by Boris Beizer [Bei95] testing should include both clean and dirty tests. Dirty tests are designed to \break" the software; clean tests are designed to demonstrate that software executes correctly. Specifications only provide clean tests.Eje: Ingeniería de Software y Base de DatosRed de Universidades con Carreras en Informática (RedUNCI

Моделі і методи тестування програмних систем

Підсумовано основні результати досліджень з проблематики тестування програмних систем (ПС). Зазначено місце та роль тестування, наведено основні методи та моделі інженерії тестування ПС оброблення даних. Запропоновано структуру базового процесу тестування та метод його оцінювання

An Empirical Investigation of the Key Factors for Refactoring Success in an Industrial Context

Refactoring is an increasingly practiced method in industrial software development. Stated simply, refactoring is an ongoing software improvement process that simplifies the internal structure of existing software, without changing its external behavior. The purpose is to improve the software and facilitate future maintenance and enhancement. Existing studies on refactoring mainly focus on its technical aspects and thus do not consider the team and human factors that influence its success. To identify the major facilitating factors for the success of refactoring, we interviewed 10 industrial software developers, and combined their responses with a study of the existing literature, formulated a model of refactoring success. The resulting conceptual model comprises both technical and non-technical factors. Technical factors include: level, testing and debugging, and tools, while the non-technical factors include: communication and coordination, support activities, individual capability/skills, and programmer participation. We propose to verify this model empirically through a survey of professional software developers (main body of refactoring practitioners). The survey design is provided

Requirements Analysis for an Integrated OCL Development Environment

An Integrated OCL Development Environment (IDE4OCL) can significantly improve the pragmatics and praxis of OCL. We present the domain concepts, toolâlevel interactions with OCL and the use cases we identified in a systematic analysis of requirements for an IDE4OCL. The domain concepts is an important contribution of our work as it attempts to clarify inconsistencies in the relevant specifications. Because OCL is not a standâalone language, the OCL landscape includes several interacting tools including an IDE4OCL. The use cases describe our vision of the desired functionality unique to an IDE4OCL. The results of our analysis and the long term vision of our work should be relevant to developers of OCL tools as well as to the OMG Request for Information regarding the UML Futures1. Our work is relevant to the UML Futures Roadmap because providing OCL for the constraints in the UML specification has been a longstanding problem at the OMG

A SOFTWARE TESTING ASSESSMENT TO MANAGE PROJECT TESTABILITY

The demand for testing services is, to a large extend a ?derived demand? influenced directly by the manner in which prior developed activities are undertaken. The early stages of a structured software development life cycle (SDLC) project can often run behind schedule, shrinking the time available for performing adequate testing especially when software release deadlines have to be met. This situation fosters the need to influence pre-testing activities and manage the testing effort efficiently. Our research examines how to measure testability of a SDLC project before testing begins. It builds on the ?design for testability? perspective by introducing a ?manage for testability? perspective. Software testability focuses on whether the activities of the SDLC process are progressing in ways that enable the testing team to find software product defects if they exist. To address this challenge, we develop a software testing assessment. This assessment is designed to provide testing managers with information needed to: (1) influence pre-testing activities in ways that ultimately increase testing efficiency and effectiveness, and (2) plan testing resources to optimize efficient and effective testing. We developed specific software testing assessment measures through interviews with key informants. We present data collected for the measures for large-scale structured software development projects to illustrate the assessment?s usefulness and application