Contributions in Merlin

Gaining higher level evolutionary information about large software systems is a key in validating past and adjusting future development processes. In this paper, we analyze the proximity of software features based on modification and problem report data that capture the system’s evolution history. Features are instrumented and tracked, the relationships of modification and problem reports to these features are established, and the tracked features are visualized to illustrate their otherwise hidden dependencies. Our approach uncovers these hidden relationships between features via problem report analysis and presents them in easy-to-evaluate visual form. Particular feature dependencies then can be selected to assess the feature evolution by zooming in into an arbitrary level of detail. Such visualization of interwoven features, therefore, can indicate locations of design erosion in the architectural evolution of a software system. Our approach has been validated using the large open source software project of Mozilla and its bug reporting system Bugzilla.

Traditional approaches for program comprehension use static program analysis or dynamic program analysis in the form of execution traces. Our approach, however, makes use of runtime-data such as parameter and object values. Compared to traditional program comprehension techniques, this approach enables fundamentally new ways of program analysis which we have not seen so far. Reflection analysis which allows engineers to understand programs making use of reflective (dynamic) method invocations is one such analysis. Another is object tracing which allows engineers to trace and track the use of a given instance of a class within the program to be understood. In this paper, we present these techniques along with a case study to which we have applied them.

Software product families are rarely created right away but they emerge when a domain becomes mature enough to sustain their long-term investments. The typical pattern is to start with a small set of products to quickly enter a new market. As soon as the business proves to be successful new investments are directed to consolidating the software assets. The various products are migrated towards a flexible platform where the assets are shared and new products can be derived from. In order to create and maintain the platform, the organization needs to carry out several activities such as recovering the architectures of single products and product families, designing the reference architecture, isolating the variable parts, and generalizing software components. In this paper, we introduce a product family construction process that exploits related systems and product families, and we describe methods and tools used. We also present an approach for classifying platforms according to platform coverage and variation and describe three techniques to handle variability across single products and whole product families.

Many extensions to text-based, data-intensive knowledge management approaches, such as Information Retrieval or Data Mining, focus on integrating the impressive recent advances in language technology. For this, they need fast, robust parsers that deliver linguistic data which is meaningful for the subsequent processing stages. This paper introduces such a parsing system. Its output is a hierarchical structure of syntactic relations, functional dependency structures.

Many of the proposed approaches to the semantic web have a substantial drawback. They are all based on the idea that web pages (or more generally, resources), will contain semantic annotations that would allow remote agents to access them. However the problem of the creation of those annotations is seldom addressed. Manual creation of the annotations is not a feasible option, except in a few experimental cases. We propose an approach based on Language Processing techniques that addresses this issue, at least for textual resources (which still constitute the vast majority of the material available on the web). Documents are analized fully automatically and converted into a semantic annotation, which can then be stored together with the original documents. It is this annotation that constitutes the machine understandable resource that remote agents can query. A semi-automatic approach is also considered, in which the system suggests candidate annotations and the user simply has to approve or reject them. Advantages and drawbacks of both approaches are discussed.

Scenarios (Use cases) – being descriptions of sequences of interactions between two or more partners, usually between a system and its users – have attracted much attention and gained wide-spread use in requirements and software engineering over the last couple of years. In scenarios, the functionality and behavior of a (software) system is captured in a user-centered perspective. To date, scenarios are mainly used in the requirements elicitation and analysis phase of software development. Even though scenarios are mainly used in system analysis, the use of scenarios in other phases of software development is of much interest, as it could help to cut cost by reuse and improved validation and verification. As scenarios form a kind of abstract test cases for the system under development, the idea to use them to derive test cases for system test is quite intriguing. Yet in practice, scenarios from the analysis phase are seldom used to create concrete system test cases. An analysis of the central problems of software testing, and of the reasons why scenarios from the analysis phase are not used for creating test cases for system test, leads us to proposing the following premises or concepts which we consider to be valuable approaches to improve testing, and that consequently serve as a basis for the approach presented in this thesis: * Reuse of analysis scenarios for validation purposes and in testing. * Integration of test methods & activities and of the methods & activities of the software development methodology used. * Creation of test cases for system test in a systematic manner and early in the development cycle. * Modeling the dependencies and relationships among scenarios and using this dependency model to refine test case derivation from the scenario model. In this document, a method is developed and described that is based on the concepts presented above and on the deficiencies found in existing approaches. A definite step-procedure for creating scenarios is defined and further use of analysis scenarios in development and testing is discussed. We call the approach the SCENT-Method: A method for SCENario-based validation and Test of software. The main issues of requirements elicitation and documentation are analyzed, and the advantages and disadvantages of formal specification languages versus natural language are discussed. A detailed step-by-step procedure for the creation of descriptive, narrative scenarios is defined and a template to help describe, structure and document natural language scenarios is presented. Natural language scenario descriptions are formalized in statecharts. This helps to avoid or at least alleviate some of the problems of natural language specifications (ambiguity, inconsistencies, imprecise or vague expressions, and the like). These statecharts – being a more formal representation of the narrative scenarios – are used to systematically derive test cases from. Furthermore, the statecharts-based functional model is annotated with non-functional requirements and data, and used to validate the system. Dependencies and relations among scenarios are captured and modeled in a special model that stands complementary to the behavioral model. This so-called SCENT dependency chart is used to derive further test cases, and thus to expand and refine the test suite created from the behavioral model. A language and a notation are defined to capture and document the dependencies among the scenarios. In an example we illustrate how to use this language and notation. The tester uses the formalized and annotated scenarios and the dependency charts for deriving test cases for system test. This is done in a systematic way by traversing paths in the statecharts and the dependency charts, respectively. First results, that have been gained by applying the method to real projects in an international company, are presented and discussed, and problems and open questions are addressed.

null

null