Feature-oriented programming
FOSD arose out of layer-based designs and levels of abstraction in network protocols and extensible database systems in the late-1980s.
FOSD has since evolved into the study of feature modularity, tools, analyses, and design techniques to support feature-based program generation.
Later, the term feature-oriented programming was coined;[3] this work exposed interactions between layers.
A third generation of research focussed on the fact that every program has multiple representations (e.g., source, makefiles, documentation, etc.)
GenVoca (a portmanteau of the names Genesis and Avoca)[1] is a compositional paradigm for defining programs of product lines.
A more advanced technique, called mixin layers, showed the connection of features to object-oriented collaboration-based designs.
Algebraic Hierarchical Equations for Application Design (AHEAD)[4] generalized GenVoca in two ways.
Every program has multiple representations, such as source, documentation, bytecode, and makefiles.
Second, AHEAD expresses features as nested tuples of unary functions called deltas.
The representations of a program are computed recursively by nested vector addition.
The Principle of Uniformity states that all program artifacts are treated and modified in the same way.
For example, the relationship between a grammar gf and its parser source sf is defined by a compiler-compiler tool, e.g., javacc.
Similarly, the relationship between Java source sf and its bytecode bf is defined by the javac compiler.
For example, one way to derive the bytecode b3 of parser p3 (lower right object in the figure to the right) from grammar gh of parser h (upper left object) is to derive the bytecode bh and refine to b3, while another way refines gh to g3, and then derive b3, where + represents delta composition and () is function or tool application: There are
possible paths to derive the bytecode b3 of parser p3 from the grammar gh of parser h. Each path represents a metaprogram whose execution generates the target object (b3) from the starting object (gf).
[5][12] A path through a diagram corresponds to a tool chain: for an FOMDD model to be consistent, it should be proven (or demonstrated through testing) that all tool chains that map one object to another in fact yield equivalent results.
