Generative Core Concepts
Program-Transformation.Org: The Program Transformation Wiki
Generative Domain Model
The key to automating the assembly of software systems is a generative domain model (GDM) that consists of a problem space, a solution space, and the configuration knowledge mapping between them (see Fig. GDM). The solution space comprises the implementation components and the common system family architecture, defining all valid combinations of the implementation components. Typically, the implementation components are designed for maximum combinability, minimum redundancy, and maximized reuse. The problem space, on the other hand, consists of the application-oriented concepts and features that application engineers use to express their needs. This space is implemented as a domain-specific language (DSL). Because of the different goals, the structure of the problem space and the structure of the solution space will be different, and they usually cannot be aligned without sacrificing simplicity and domain-specificity in the problem space or reuse and flexibility in the solution space. The configuration knowledge specifies illegal feature combinations, default settings, default dependencies (some defaults may be computed based on some other features), construction rules (combinations of certain features translate into certain combinations of implementation components), and optimizations. The configuration knowledge may be implemented using different forms of metaprogramming, e.g., dynamic reflection, object factories, and program generators. The automatically created products may also contain non-software artifacts, such as test plans, manuals, tutorials, maintenance guidelines, etc. -- KrzysztofCzarnecki - 28 Nov 2002- Fig. GDM: Elements of a generative domain model: [from the GenerativeProgrammingBook]
Network of Domains
One important observation about a GDM is that it can be viewed recursively, i.e., someone's problem space may be someone else's solution space. Furthermore, one DSL may be implemented using many DSLs from other domains. In general, we get a network of domains that may also contain cycles (see Fig. DN). This concept was introduced by JimNeighbors. -- KrzysztofCzarnecki - 28 Nov 2002- Fig. DN: Example of a network of domains:
Technology Projections
Each of the elements of a generative domain model can be implemented using different technologies, which gives rise to different technology projections (see Fig. TP):- Components can be implemented using, e.g., generic components (such as in the STL), component models (e.g., JavaBeans?, ActiveX?, or CORBA), or aspect-oriented programming approaches.
- Generators can be implemented using preprocessors (e.g., template processors), application generators, built-in metaprogramming capabilities of a language (e.g., template metaprogramming in C++), or extendible programming systems.
- DSLs can be implemented using new textual or graphical languages (or language extensions), programming language-specific features, or interactive wizards.
- Fig. TP: Technology projections:
Drawing the Map
Fig. GM classifies a number of fields by relating them to the elements of a generative domain model. (this figure was taken from the report on the ECOOP'01 workshop on Generative Programming). Components, architectures, and generic programming are primarily related to the solution space. Aspect-oriented programming provides more powerful encapsulation mechanisms than traditional component technologies. In particular, it allows us to replace many "little, scattered components" (such as those needed for logging or synchronization) and the configuration knowledge related to these components by well encapsulated aspectual modules. However, we still need to configure aspects and other components to implement abstract features such as performance properties. Therefore, aspect-oriented programming technologies such as AspectJ cover the solution space and only a part of the configuration knowledge. But aspects can be also found in the problem space, esp. in the context of DSLs used to described different aspects of a single system (the original workshop figure did not have this "aspect-oriented DSLs" entry). The problem space and the front part of the configuration knowledge are addressed by areas such as DSLs, feature modeling, and feature interactions. Finally, system family and product line engineering span across the entire generative domain model because they provide the overall structure of the development process (including DomainEngineering and ApplicationEngineering?). -- KrzysztofCzarnecki - 28 Nov 2002- Fig. GM: The map:
CategoryGenerativeProgrammingWiki