You are here:
(27 Nov 2007,
--------------------------------++ 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
ore topic actions
Topic revision: r4 - 27 Nov 2007,
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding UUCS?