ARBEITSGRUPPE

DATENBANKEN UND

SOFTWARE ENGINEERING

• Implementation of efficient build, update, or search algorithms for Elf
• Critical evaluation against state-of-the-art competitors

• Syntax Validation: The syntax of the query is verified in this step.
• Semantics Verification: Here, Type checking and verification of valid column references will be performed.
• Query Evaluation: The query is evaluated using database engine. Its relational algebra statement will be translated to an SQL statement and then executed against a database.

• General primitive based execution of TPC-H queries
• Variants of the primitives
• Analytical report on the primitive-based execution

• programming in C++ & OpenCL and Python/R (for charting)

• Determine the current-state-of-art related to approaches for reporting of an SLR
• Propose and evaluate your concept to semi-automate the steps involved in this phase

• Extend existing prototype to assess quality of empirical studies
• Evaluate the proposed approach

Elias Kuiter

Software Product Lines, Feature Modeling

Software product lines (SPLs) are collections of many software products (called configurations) that share certain characteristics (called features). Thus, SPLs can be used to develop and maintain variant-rich, highly-customizable software systems (e.g., the Linux kernel). The variability of an SPL is made explicit in a feature model, which is typically visualized as a tree-like feature diagram. The tree structure of this diagram makes it hard to express complex dependencies between features, which are therefore expressed as additional propositional formulas (called cross-tree constraints). Such complex feature dependencies may cause inconsistencies in a feature model like dead features, which cannot be selected in any configuration.

A feature model of a configurable system can contain several inconsistencies (besides dead features, also false-optional features or redundant cross-tree constraints). There are analyses for detecting these kinds of inconsistencies; however, there is user action required to actually fix them. The aim of this thesis is to investigate how and to what degree this process can be automatized; that is, whether feature models can be “cleaned” with a simple and intuitive procedure.

• Compare and discuss suitable strategies for cleaning (e.g., which redundant constraints to remove)
• Implement promising strategies in FeatureIDE
• Evaluate usability in a user study

Completion of ISP is strongly recommended.

Elias Kuiter

Software Product Lines, Highly-Configurable Software, Constraint Programming

Software product lines (SPLs) are collections of many software products (called configurations) that share certain characteristics (called features). Thus, SPLs can be used to develop and maintain variant-rich, highly-customizable software systems (e.g., the Linux kernel). The variability of an SPL is made explicit in a feature model, which is typically visualized as a tree-like feature diagram. This feature model is then used to create concrete configurations, a process that is typically supported within an advanced configuration editor. Such editors use state-of-the-art analysis techniques that are based on constraint programming with SAT/CSP solvers.

Attributed feature models extend common feature models with attributes for certain features like costs, memory consumption, or performance impact. In state-of-the-art tooling, such attributes cannot be used in configurations, which is however one of the main reasons to use attributes in the first place (for example, to set a maximum cost allowance). The aim of this thesis is to extend the configuration editor of FeatureIDE (a tool for developing SPLs) such that it allows to limit the value range of attributes during configuration. Additionally common analyses for configurations (such as checking validity, auto-completion, or decision propagation) should also be considered.

• Develop a concept and implementation to support configuration of attributed feature models
• Adapt existing analyses for the configuration editor
• Evaluate performance and/or usability

Completion of ISP is strongly recommended.

Elias Kuiter

Software Product Lines, Feature Modeling, Constraint Programming

Software product lines (SPLs) are collections of many software products (called configurations) that share certain characteristics (called features). Thus, SPLs can be used to develop and maintain variant-rich, highly-customizable software systems (e.g., the Linux kernel). The variability of an SPL is made explicit in a feature model, which is typically visualized as a tree-like feature diagram. The tree structure of this diagram makes it hard to express complex dependencies between features, which are therefore expressed as additional propositional formulas (called cross-tree constraints). Such complex feature dependencies may cause inconsistencies in a feature model like dead features, which cannot be selected in any configuration. To avoid these inconsistencies, state-of-the-art tooling uses analysis techniques that are based on constraint programming with SAT/CSP solvers.

Attributed feature models extend common feature models with attributes for certain features like costs, memory consumption, or performance impact. In state-of-the-art tooling, such attributes cannot be used in cross-tree constraints, which is however one of the main reasons to use attributes in the first place (for example, to set ranges for integer attributes). The aim of this thesis is to extend the feature model editor of FeatureIDE (a tool for developing SPLs) to allow for cross-tree constraints over attributes. Additionally common feature model analyses (such as checking the validity of a feature model, finding dead/core features, or finding redundant constraints) should also be considered.

• Develop a concept and implementation to support constraints over (at least) integer and enumeration attributes
• Adapt existing feature model analyses to such constraints
• Evaluate performance on several feature models

Completion of ISP is strongly recommended.

Elias Kuiter

Software Product Lines, Feature Modeling, Propositional Logic

Software product lines (SPLs) are collections of many software products (called configurations) that share certain characteristics (called features). Thus, SPLs can be used to develop and maintain variant-rich, highly-customizable software systems (e.g., the Linux kernel). The variability of an SPL is made explicit in a feature model, which is typically visualized as a tree-like feature diagram. This feature model is then used to create concrete configurations, a process that is typically supported within an advanced configuration editor. To support the feature modeling and configuration processes, state-of-the-art tooling uses analysis techniques that are based on SAT solver technology.

Hidden features can be used to mark features that are not configurable by end users, but are automatically (de-)selected by the configuration editor according to additional constraints in the feature model. A hidden feature is called indeterminate if there is at least one configuration in which all regular features are defined but a value for the hidden feature cannot be deduced. Indeterminate hidden features can cause problems during configuration and should therefore be detected beforehand, which is a time-consuming task. The aim of the thesis is to optimize the current analysis in FeatureIDE (a tool for developing SPLs) for finding indeterminate hidden features to improve its performance and therefore applicability in the field.

• Develop an improved analysis for finding indeterminate hidden features in FeatureIDE
• Evaluate the new analysis by comparing it to previous algorithms

Completion of ISP is strongly recommended.

Elias Kuiter

Software Product Lines, Feature Modeling, Propositional Logic

Software product lines (SPLs) are collections of many software products (called configurations) that share certain characteristics (called features). Thus, SPLs can be used to develop and maintain variant-rich, highly-customizable software systems (e.g., the Linux kernel). The variability of an SPL is made explicit in a feature model, which is typically visualized as a tree-like feature diagram. This feature model is then used to create concrete configurations, a process that is typically supported within an advanced configuration editor. To support the feature modeling and configuration processes, state-of-the-art tooling uses analysis techniques that are based on SAT solver technology.

Counting how many configurations a feature model comprises can be a time-consuming task — however, sometimes it is sufficient to know an estimation of the number of configurations. There are already algorithms for precisely and approximately counting the number of configurations that a feature model represents. The aim of this thesis is to create a systematic overview of all available methods for exact and approximate configuration counting. The overview should contain a comparison of the differences between the researched methods in efficiency and accuracy. At least one approximate counting approach should be implemented in FeatureIDE and evaluated against contemporary SAT and #SAT approaches.

• Systematic research and survey of methods for (approximate) configuration counting for feature models
• Evaluate and compare the researched methods

Completion of ISP is strongly recommended.

Elias Kuiter

Software Product Lines, Software Testing, Evolution

Software product lines (SPLs) are collections of many software products (called configurations) that share certain characteristics (called features). Thus, SPLs can be used to develop and maintain variant-rich, highly-customizable software systems (e.g., the Linux kernel). A key challenge in managing SPLs is the potentially large (exponential) number of products, which makes it hard to test all products in an SPL — for example, there are easily more variants of the Linux kernel than there are atoms in the universe. In practice, this means that testing an SPL often amounts to testing some number of configurations and hoping that such a configuration sample covers most potential faults in the SPL. One class of faults in SPLs are so-called feature interactions, which are bugs that only occur for very specific combinations of selected features. For example, two device drivers in the Linux kernel may work fine on their own, but be incompatible with each other, which causes crashes when both drivers are loaded at the same time.

A contemporary technique for testing SPLs is to generate a representative set of configurations (i.e., a configuration sample) and run tests for every configuration in the sample. However, generating such samples can be time-intensive, and if the SPL is changed, samples become invalid and must be generated completely from scratch. The aim of this thesis is to find an efficient technique to update an existing sample such that it can accommodate changes to the SPL. Thus, after changes to the feature model (which expresses the valid configurations of an SPL) have been made, parts of an existing sample should be reused to avoid complete re-calculation.

• Develop and implement a technique for efficiently updating a configuration sample after feature model evolution
• Evaluate the proposed approach

Completion of ISP is strongly recommended.

Elias Kuiter

Software Product Lines, Software Testing

Software product lines (SPLs) are collections of many software products (called configurations) that share certain characteristics (called features). Thus, SPLs can be used to develop and maintain variant-rich, highly-customizable software systems (e.g., the Linux kernel). A key challenge in managing SPLs is the potentially large (exponential) number of products, which makes it hard to test all products in an SPL — for example, there are easily more variants of the Linux kernel than there are atoms in the universe. In practice, this means that testing an SPL often amounts to testing some number of configurations and hoping that such a configuration sample covers most potential faults in the SPL. One class of faults in SPLs are so-called feature interactions, which are bugs that only occur for very specific combinations of selected features. For example, two device drivers in the Linux kernel may work fine on their own, but be incompatible with each other, which causes crashes when both drivers are loaded at the same time.

A contemporary technique for testing SPLs is to generate a representative set of configurations (i.e., a configuration sample) and run tests for every configuration in the sample. In case one configuration fails some tests, the developers have to fix the corresponding fault in the SPL. The aim of this thesis is to detect the feature interaction(s) responsible for such a fault. That is, given a configuration sample for an SPL and some configuration(s) in the sample that fail a test, your technique should find the smallest set of selected features that is necessary to fail the test. This set then indicates the feature interaction to the developer, who can use this information to fix the corresponding bug.

• Investigate techniques to find faulty feature interactions for a given configuration sample
• Evaluate the performance of these techniques

Completion of ISP is strongly recommended.

• User Statistiken über bearbeitete Aufgaben
• User Account Management
• Erfassung mehrerer Jahrgänge
• Duplizierung von Aufgaben
• Check der Korrektheit der Aufgaben bei deren Erstellung
• Einreichung ER-Aufgaben

• Implementierung weiterer Funktionen im SQL Validator

• Recherche und Implementierung von Algorithmen zur Datenqualitätsanalyse
• API Integration mit Intel/AMD
• Duplikate finden und bereinigen

1. You have had a course for Database Implementations (e.g., Databases II) or similar
2. You have had a course for Modern Database Concepts (e.g., Advanced Topics in Databases) or similar
3. You have had a course for C (C++) programming (e.g., Architecting and Engineering Main Memory Database Systems in Modern C) or practice of C programming

1. You have had a course for Database Implementations (e.g., Databases II) or similar
2. You have had a course for Modern Database Concepts (e.g., Advanced Topics in Databases) or similar
3. You have had a course for C (C++) programming (e.g., Architecting and Engineering Main Memory Database Systems in Modern C) or practice of C programming

1. You have had a course for Database Implementations (e.g., Databases II) or similar
2. You have had a course for Modern Database Concepts (e.g., Advanced Topics in Databases) or similar
3. You have had a course for C (C++) programming (e.g., Architecting and Engineering Main Memory Database Systems in Modern C) or practice of C programming

1. You have had a course for Database Implementations (e.g., Databases II) or similar
2. You have had a course for Modern Database Concepts (e.g., Advanced Topics in Databases) or similar
3. You have had a course for C (C++) programming (e.g., Architecting and Engineering Main Memory Database Systems in Modern C) or practice of C programming

1. You have had a course for Database Implementations (e.g., Databases II) or similar
2. You have had a course for Modern Database Concepts (e.g., Advanced Topics in Databases) or similar
3. You have had a course for C (C++) programming (e.g., Architecting and Engineering Main Memory Database Systems in Modern C) or practice of C programming