Overview (Getting Started)

When faced with the problem of designing a program, most of us think of OO classes.  When faced with the problem of designing families of related programs, there is an overwhelming evidence that we should think in terms of features, where a feature is an increment in program functionality.  Feature Oriented Programming (FOP) is the the study of feature modularity, where features are raised to first-class entities in design.  Features are implemented by cross-cuts that are modifications or extensions to multiple classes.  Unlike AOP aspects, whose focus is on quantification -- i.e., specifying predicates that identify join points at which to insert code -- feature implementations are actually much closer to OO framework designs.  That is, to add a feature to an OO framework, there are predefined methods and classes that are to be extended.  In such designs, there is little or no quantification, but there are indeed "cross-cuts".  This is the approach that we have used for years in building program families (a.k.a. product-lines).

Algebraic Hierarchical Equations for Application Design (AHEAD) is an example of FOP.  It is a simple and general algebraic model of program synthesis that is based on step-wise refinement -- a methodology that advocates that complex systems can be built by adding features incrementally.  FOP and AHEAD address a fundamental problem in software engineering -- a path to its future.

The future of software engineering lies in automation.  The best practical example of automated software engineering is relational query optimization.  That is, database queries are expressed using a declarative specification (SQL) that is mapped to an efficient program.  The general problem of mapping from a declarative spec to a provably efficient program is very difficult -- it is called automatic programming.  The success of relational databases rests on relational algebra -- a set of fundamental operations on tables -- and that query evaluation programs are  expressions -- compositions of relational algebra operations.  Optimizers use algebraic identities to rewrite, and hence optimize, expressions, which in turn optimizes query evaluation programs.  This is how databases "solve" the automatic programming problem for query evaluation programs.

AHEAD is a generalization of the relational query optimization paradigm.  AHEAD domain models are algebras (e.g., constants and functions), and programs are represented by expressions -- function compositions.  Just as in relational algebra, different domain models have their own algebraic identities that can be used for expression optimizing . Further, both code and non-code artifacts are treated uniformly in AHEAD, so that all artifacts -- both code and non-code -- are consistent when they are synthesized.  More importantly, equational representations of program scale. We are synthesizing the AHEAD tool suite (which is over 150K LOC Java) from simple declarative specifications (which we represent equationally).

To get a feel for the basic issues involved and their breadth, I recommend the following papers (and read them in this order):

Notes from my most recent tutorial and tutorial examples are available below:

• Most Recent Tutorial Notes (1MB PDF file)
• Tutorial Examples

For further information, contact Don Batory.