History
FOSD arose out of layer-based designs and levels of abstraction in network protocols and extensible database systems in the late-1980s. A program was a stack of layers. Each layer added functionality to previously composed layers and different compositions of layers produced different programs. Not surprisingly, there was a need for a compact language to express such designs. Elementary algebra fit the bill: each layer was a function (a program transformation) that added new code to an existing program to produce a new program, and a program's design was modeled by an expression, i.e., a composition of transformations (layers). The figure to the left illustrates the stacking of layers i, j, and h (where h is on the bottom and i is on the top). The algebraic notations i(j(h)), i•j•h, and i+j+h have been used to express these designs. Over time, layers were equated to features, where a ''feature'' is an increment in program functionality. The paradigm for program design and generation was recognized to be an outgrowth of relational query optimization, where query evaluation programs were defined as relational algebra expressions, andGenVoca
GenVoca (a portmanteau of the names Genesis and Avoca) is a compositional paradigm for defining programs of product lines. Base programs are 0-ary functions or transformations called values: f -- base program with feature f h -- base program with feature h and features are unary functions/transformations that elaborate (modify, extend, refine) a program: i + x -- adds feature i to program x j + x -- adds feature j to program x where + denotes function composition. The ''design'' of a program is a named expression, e.g.: p1 = j + f -- program p1 has features j and f p2 = j + h -- program p2 has features j and h p3 = i + j + h -- program p3 has features i, j, and h A GenVoca model of a domain or software product line is a collection of base programs and features (see MetaModels and Program Cubes). The programs (expressions) that can be created defines a product line. Expression optimization is ''program design optimization'', and expression evaluation is ''program generation''. : Note: GenVoca is based on the stepwise development of programs: a process that emphasizes design simplicity and understandability, which are key to program comprehension and automated program construction. Consider program p3 above: it begins with base program h, then feature j is added (read: the functionality of feature j is added to the codebase of h), and finally feature i is added (read: the functionality of feature i is added to the codebase of j•h). : Note: not all combinations of features are meaningful. Feature models (which can be translated into propositional formulas) are graphical representations that define legal combinations of features. : Note: A more recent formulation of GenVoca is symmetric: there is only one base program, 0 (the empty program), and all features are unary functions. This suggests the interpretation that GenVoca composes program structures by superposition, the idea that complex structures are composed by superimposing simpler structures. Yet another reformulation of GenVoca is as a#ifdef feature ... #endif
) techniques. A more advanced technique, called mixin layers, showed the connection of features to object-oriented collaboration-based designs.
AHEAD
Algebraic Hierarchical Equations for Application Design (AHEAD) generalized GenVoca in two ways. First it revealed the internal structure of GenVoca values as tuples. Every program has multiple representations, such as source, documentation, bytecode, and makefiles. A GenVoca value is a tuple of program representations. In a product line of parsers, for example, a base parser f is defined by its grammar gf, Java source sf, and documentation df. Parser f is modeled by the tuple f= f, sf, df">f, sf, df Each program representation may have subrepresentations, and they too may have subrepresentations, recursively. In general, a GenVoca value is a tuple of nested tuples that define a hierarchy of representations for a particular program. :: Example. Suppose terminal representations are files. In AHEAD, grammar gf corresponds to a single BNF file, source sf corresponds to a tuple of Java files 1…cn">1…cn and documentation df is a tuple of HTML files 1…hk">1…hk A GenVoca value (nested tuples) can be depicted as a directed graph: the graph for parser f is shown in the figure to the right. Arrows denote projections, i.e., mappings from a tuple to one of its components. AHEAD implements tuples as file directories, so f is a directory containing file gf and subdirectories sf and df. Similarly, directory sf contains files c1…cn, and directory df contains files h1…hk. :: Note: Files can be hierarchically decomposed further. Each Java class can be decomposed into a tuple of members and other class declarations (e.g., initialization blocks, etc.). The important idea here is that the mathematics of AHEAD are recursive. Second, AHEAD expresses features as nested tuples of unary functions called deltas. Deltas can be program refinements (semantics-preserving transformations), extensions (semantics-extending transformations), or interactions (semantics-altering transformations). We use the neutral term “delta” to represent all of these possibilities, as each occurs in FOSD. To illustrate, suppose feature j extends a grammar by gj (new rules and tokens are added), extends source code by sj (new classes and members are added and existing methods are modified), and extends documentation by dj. The tuple of deltas for feature j is modeled by j= \Deltagj,sj,dj">math>\Deltagj,sj,dj which we call a delta tuple. Elements of delta tuples can themselves be delta tuples. Example: sj represents the changes that are made to each class in sf by feature j, i.e., sj= \Deltac1…cn">math>\Deltac1…cn The representations of a program are computed recursively by nested vector addition. The representations for parser p2 (whose GenVoca expression is j+f) are: p2 = j + f -- GenVoca expression = \Deltagj, sj, dj">math>\Deltagj, sj, dj+ f, sf, df">f, sf, df -- substitution = \Deltagj+gf, sj+sf, dj+df">math>\Deltagj+gf, sj+sf, dj+df -- compose tuples element-wise That is, the grammar of p2 is the base grammar composed with its extension (gj+gf), the source of p2 is the base source composed with its extension (sj+sf), and so on. As elements of delta tuples can themselves be delta tuples, composition recurses, e.g., sj+sf= \Deltac1…cn">math>\Deltac1…cn 1…cn">1…cn \Deltac1+c1…cn+cn">math>\Deltac1+c1…cn+cn Summarizing, GenVoca values are nested tuples of program artifacts, and features are nested delta tuples, where + recursively composes them by vector addition. This is the essence of AHEAD. The ideas presented above concretely expose two FOSD principles. The Principle of Uniformity states that all program artifacts are treated and modified in the same way. (This is evidenced by deltas for different artifact types above). The Principle of Scalability states all levels of abstractions are treated uniformly. (This gives rise to the hierarchical nesting of tuples above). The original implementation of AHEAD is the AHEAD Tool Suite and Jak language, which exhibits both the Principles of Uniformity and Scalability. Next-generation tools include CIDE and FeatureHouse.FOMDD
Feature-Oriented Model-Driven Design (FOMDD) combines the ideas of AHEAD with Model-Driven Design (MDD) (a.k.a. Model-Driven Architecture (MDA)). AHEAD functions capture the lockstep update of program artifacts when a feature is added to a program. But there are other functional relationships among program artifacts that express derivations. 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. AApplications
* tp://ftp.cs.utexas.edu/pub/predator/tosem-92.pdf Network Protocols* tp://ftp.cs.utexas.edu/pub/predator/tosem-92.pdf Extensible Database Systems* tp://ftp.cs.utexas.edu/pub/predator/sigsoft-93.pdf Data Structures* tp://ftp.cs.utexas.edu/pub/predator/fsatsRevised.pdf Distributed Army Fire Support Simulator* tp://ftp.cs.utexas.edu/pub/predator/sigsoft-94.pdf Production System Compiler* tp://ftp.cs.utexas.edu/pub/predator/GPL.pdf Graph Product Line* tp://ftp.cs.utexas.edu/pub/predator/ahead.pdf Extensible Java Preprocessors* tp://ftp.cs.utexas.edu/pub/predator/ICSE07.pdf Web Portlets* tp://ftp.cs.utexas.edu/pub/predator/icmt08.pdf SVG ApplicationsSee also
* FOSD metamodels – product lines of product lines *References