FOSD program cubes
This article may require cleanup to meet Wikipedia's quality standards. (September 2011) (Learn how and when to remove this template message)

In featureoriented software development, featureoriented software development program cubes (FOSD program cubes) are ndimensional arrays of functions (program transformations) that represent ndimensional product lines. A program is a composition of features: a base program is augmented with increments in program functionality, called features, to produce a complex program. A software product line (SPL) is a family of related programs. A typical product line has F_{0} as a base program, and F_{1}..F_{n} as features that could be added to F_{0}. Different compositions of features yield different programs. Let + denote the feature composition operation. A program P in SPL might have the following expression:
P = F_{8} + F_{4} + F_{2} + F_{1} + F_{0}
That is, P extends program F_{0} with features F_{1}, F_{2}, F_{4}, and F_{8} in this order.
We can recast P in terms of a projection and contraction of a 1dimensional array. Let F_{i} = [F_{0} .. F_{n}] denote the array of features used by a product line. A projection of F_{i} eliminates unneeded features, yielding a shorter array (call it) G_{i}. A contraction of G_{i} sums each G_{i} in a specific order, to yield a scalar expression. The expression for P becomes:
P = F_{i}
where the index values accomplish projection and summation is array contraction. This idea generalizes to ndimensional arrays that model multidimensional product lines.
Multidimensional product lines
A multidimensional product line is described by multiple interacting sets of features.^{[1]} ^{[2]} ^{[3]} ^{[4]} As an elementary 2D example, it is easy to create a product line of calculators, where variants offer different sets of operations. Another variation might offer different presentation front ends to calculators, one with no GUI, another with a Java GUI, a third with a web GUI. These variations interact: each GUI representation references a specific calculator operation, so each GUI feature cannot be designed independently of its calculator feature. Such a design leads to a matrix: columns represent increments in calculator functionality, and rows represent different presentation frontends. Such a matrix M is shown to the right: columns allow one to pair basic calculator functionality (base) with optional logarithmic/exponentiation (lx) and trigonometric (td) features. Rows allow one to pair core functionality with no frontend (core), with optional GUI (gui) and webbased (web) frontends.
An element M_{ij} implements the interaction of column feature i and row feature j. For example, the element labeled cb is a base program that implements the core functionality of a calculator. Element gb adds code that displays the core functionality as a GUI; element wb adds code that displays the core functionality via the web. Similarly, element ct adds trigonometric code to the core calculator functionality; elements gt and wt add code to display the trigonometric functionality as a GUI and web frontends.
A calculator is uniquely specified by two sequences of features: one sequence defines the calculator functionality, the other the frontend. For example, calculator C that offers both base and trig functionality in a web format is defined by the expression:
C = M_{cb} + M_{ct} + M_{wb} + M_{wt} = M_{ij}
 Note: Each dimension is a collection of base programs and features. Not all of their compositions are meaningful. A feature model defines the legal combinations of features. Thus, each dimension would have its own feature model. It is possible that selected features along one dimension may preclude or require features along other dimensions. In any case, these feature models define the legal combinations of features in a multidimensional product line.
Cubes
In general, a cube is an ndimensional array. The rank of a cube is its dimensionality. A scalar is a cube of rank 0, a vector is a cube of rank 1, and a matrix is rank 2. Following tensor notation: the number of indices a cube has designates its rank. A scalar S is rank 0 (it has no indices), V_{k} is a vector (rank 1), M_{ij} is a matrix (rank 2), C_{ijk} is a cube (rank 3).
Program Cubes are ndimensional arrays of functions (program transformations) that represent ndimensional product lines. The values along each axis of a cube denote either a base program or a feature that could elaborate a base program. The rank of a product line is the rank of its cube.
 Note: program cubes are inspired by tensors and data cubes in databases. The primary difference is that data cube elements are numerical values that are added during cube contraction; program cube elements are transformations that are composed. Both use tensor notations and terminology.
A program in an ndimensional SPL is uniquely specified by n sequences of features S_{1}..S_{n}, one per dimension. The design of a program is a scalar (expression) that is formed by (1) projecting the cube of its unneeded elements, and (2) contracting the resultant kcube to a scalar:
P = K_{i1...in}
Program generation is evaluating the scalar expression to produce program P.
An interesting property of cube design is that the order in which dimensions are contracted does not matter—any permutation of dimensions during contraction results in a different scalar expression (i.e. a different program design), but all expressions produce the same value (program). For example, another expression (design) to produce calculator C contracts dimensions in the opposite order from its original specification:
C = M_{cb} + M_{wb} + M_{ct} + M_{wt}
Or more generally:
P = K_{i1...in}
 Note: Underlying cube designs is a commuting diagram, such that there are an exponential number of paths from the empty program 0 to program P. Each path denotes a particular contraction of a cube, and corresponds to a unique incremental design of P. Included among these paths are cube aggregations that contract cubes using different dimensional orders.
The significance of program cubes is that it provides a structured way in which to express and build multidimensional models of SPLs. Further, it provides scalable specifications. If each dimension has k values, an ncube specification of a program requires O(kn) terms, as opposed to O(k^{n}) cube elements that would otherwise have to be identified and then composed. In general, cubes provide a compact way to specify complex programs.
Applications
The expression problem (EP; a.k.a. the extensibility problem) is a fundamental problem in programming languages aimed at type systems that can add new classes and methods to a program in a typesafe manner.^{[5]}^{[6]}^{[7]}^{[8]} It is also a fundamental problem in multidimensional SPL design. The expression problem is an example of an SPL of rank 2. The following applications either explain/illustrate the expression problem or show how it scales to product lines of large programs. EP is really a SPL of ~30 line programs; the applications below show how these ideas scale to programs of >30K lines (a 10^{3} increase in size).
 Expression Problem
 Illustration of Small Expression Problem
 Extensible IDEs
 MultiDimensional Separation of Concerns
 Calculator Product Line
Also, FOSD metamodels can be viewed as special cases of program cubes.
References
 ^ "Generating ProductLines of ProductFamilies" (PDF).
 ^ "Refinements and MultiDimensional Separation of Concerns" (PDF).
 ^ "Scaling StepWise Refinement" (PDF).
 ^ "Evaluating Support for Features in Advanced Modularization Technologies" (PDF).
 ^ "Userdefined types and procedural data structures as complementary approaches to data abstraction".
 ^ "ObjectOriented Programming versues Abstract Data Types" (PDF).
 ^ "The Expression Problem".
 ^ "Synthesizing ObjectOriented and Functional Design to Promote ReUse".