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 overwhelming evidence to think in terms of features -- increments in program functionality. Feature Oriented Software Development (FOSD) 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 can be extended. In such designs, there is 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. software product-lines (SPLs).
Algebraic Hierarchical Equations for Application Design (AHEAD) is an example of FOSD. 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. FOSD and AHEAD address a fundamental problem in software engineering, and 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, compositional representations of program scale. We are synthesizing the AHEAD tool suite (which is over 250K LOC Java) from simple compositional and declarative specifications.
To get a feel for the basic issues involved and their breadth, I recommend the following topics in this order: