Course Description

Seminar on Software Generation and Configuration

Managing the variability in software systems is rapidly becoming an important factor in software development. Instead of developing and deploying a ``fixed'' one-of-kind system, it is now common to develop a family of systems whose members differ with respect to functionality or technical facilities offered. As a simple example, consider a software development environment that is delivered in a light, professional, and enterprise version, each providing increasing amounts of functionality. As another source for variability, modern systems need to run on different computing platforms and provide a user interface in different natural languages and possibly interaction styles. Finally, systems typically offer extensive means for configuration and customization during installation, startup, and run-time. Again, this extends the space of actual systems of the family.

An important reason for explicitly introducing variability into a system is to obtain reuse of software. Building a separate system for each variant means that the overall development effort and time will increase, and that time to market will be seriously affected. In addition, having multiple systems with significant overlap among them seriously affects the programming and management effort needed in maintenance.

The realization of variability in systems can be achieved using a wide range of techniques. These techniques can be classified into generation of a specific system from a specification of its features, or configuration of a generic system in order to restrict it to the desired set of features.

In this seminar we will study the notion of variability in software systems and generation and configuration techniques for realization of variability, by reading and discussing key papers about the various aspects of variability management.

Participants are expected to read all papers before sessions and to give presentations about several of the papers.

Literature

The literature for the seminar consists of a series of papers, links to which will be published on the following page:

• Course literature

Course Form

This is a seminar in which participants read publications from the scientific literature and give presentations about these papers. The plan is to have two presentations per session and two sessions per week. In order to compare the various techniques students should try out the various techniques on representative (but scaled down) problems. The results of these experiments should be reported in a paper.

Examination

The grade for the seminar is based on the grades for the presentations (50%) and for the paper (50%).

Variability in Software Systems

Terminology

• Feature
• Variant
• Variation point
• Binding of a variation point
• Binding time
• Timeline variation
• Crosscutting feature
• Software product line

Functional variability

The principal type of variability is functional variability, i.e. the variability in the features provided by a software system. This type of variability is directly apparent to users of a system.

• Examples of functional variability
• Why not provide all possible functionality?

Technical variability

The second type of variability is technical variability, i.e. the variability in implementation techniques used in the realization and deployment of a system. A given set of functional features may be cast in many different ways into an operational system. It may be necessary to support different realizations. For instance, a system may have to run on multiple platforms.

• Platform
• Architecture
• Design
• Implementation

• Paralellel vs sequential
• Distributed vs client-server vs webservice
• Libraries / dependencies
• Compile-time vs start-up time vs run-time

• Is technical variability an issue in the area of virtual machines?
• Can all variability be run-time?

• Variability and the evolution time-line

Modeling Variability

The variation points of a software systems are often hidden in different parts of the source tree, or even in undocumented design decisions. A unified variability model makes these variation points explicit.

• Feature diagrams
• Binary decision diagrams

Variability Scenarios

Variability engineering can play a role in many software development scenarios.

• Domain engineering
• Variability discovery
• Software components
  • Component-based software development
• Software product lines
• Model-driven approaches
  • Domain-specific languages
  • Model driven architecture (MDA)
• Separation of concerns
• Software deployment
• Run-time (re)configuration
• Transformational approaches
• Generative approaches
• Open compilers

Concrete Case Studies

• Linux kernel configuration
• Apache
• Embedding regular expressions
• GenWiki?

Meta Variability

Questions and remarks about software variability

• The main point of explicit variability is to avoid code duplication, i.e. to reuse code in new systems?
• What technique to use when creating a system with a certain type of variability?
• How does software evolution fit in software variability?
• Defer all variability to run-time!? (The Java way)
• Is technical variability an issue in the era of portable virtual machines?
• Can all variability be run-time?
• Why not provide all possible functionality?

Realizing Variablity

There are many different approaches to capturing variability.

Component Frameworks and Composition Mechanisms

The ideal to implementing variability is to implement 'features' in separate components and create a system by composing the appropriate components.

• Dynamic linking
• DotNet? Assemblies
• Enterprise Java Beans

Domain-Specific Languages and Generators

When the variability in a domain becomes complex it may be attractive to capture its concepts in a high-level domain-specific language. Software systems can then be generated from programs in that language.

• Domain-specific languages
• Software generators
• Frame technology
• Generative programming
• Active libraries

Interpreters and Partial Evaluation

The implementation of a generator for a DSL can be a considerable effort. Developing an interpreter is often much easier. Interpretative techniques can be used to turn a specific program into a generic program that 'interprets' configuration information. The overhead induced by such interpretative programs can be reduced by specializing the generic program to a specific configuration by means of partial evaluation.

• Generic programs
• Partial evaluation
• Just-in time code generation

Model-driven Approaches

• Model-driven architecture (MDA)
• Feature-oriented programming (FOP)
• FODA

Template and Staged Meta-Programming

Instead of building a separate interpreter, meta-programming environments allow the embedding of an interpreter/specializer in the In template meta-programming code templates embedded in the program are instantiated at compile-time and the generated code included in the program. In staged meta-programming the evaluation of a program is divided in several phases. Typically, in two-stage evaluation some code is evaluated at compile-time and the remaining code is evaluated at run-time.

• Template meta-programming
  • Template Haskell
  • MetaAspectJ?
  • C++ templates
• Staged meta-programming
  • MetaML?
  • MetaOCaml?

Separation of Concerns

Developing programs that support variability requires programmers to deal with many different issues in the same piece of code. Approaches to 'separation of concerns' programming allow the different concerns that are addressed in a program to be expressed in separate pieces of code.

• Adaptive programming
  • Demeter
• Aspect-oriented programming
  • AspectJ?
  • Splice (aspects with data-flow analysis)
• Strategic programming
  • Stratego
  • Strafunski
  • Visitor combinators
• Generic programming
  • Polytypic programming
  • Generic Haskell
• HyperJ?

Program Transformation

Many of the techniques above are forms of program transformation.

• Invasive software composition
• Optimization
• Instrumentation