h t t p s : / / g s d . u w a t e r l o o . c a / s i t e s / d e f a u l t / f i l e s / e s e c 9 9 . p d f

Ingest: Components and Generative Programming

Type: kb/sources/types/ingest-report.md

Classification

This invited ESEC/FSE 1999 conference paper combines a position argument, a worked C++ product-line design, and brief reports of larger applications. Its primary evidential genre is a scientific paper, although it does not present a controlled evaluation. Author: Krzysztof Czarnecki, then at DaimlerChrysler AG Research and Technology, and Ulrich W. Eisenecker, then at the University of Applied Sciences Heidelberg, write as researchers and practitioners developing generative-programming methods and implementations.

Summary

The paper argues that reusable software production should move from manually adapting and assembling components to engineering system families and then generating family members from abstract requirements. Domain engineering supplies the scope and feature model, common product-line architecture, parameterized components, configuration knowledge, and generator; application engineering supplies a member specification. The generator checks buildability where necessary, fills defaults or optimizes choices, and assembles a concrete system. A worked C++ car family and several reported library applications show the intended mechanism. For current decisions, the paper is strong historical and technical evidence that product generation can be computational while the family-specific production machinery remains deliberately engineered rather than learned from experience.

Quotes

  • Source extract (verbatim): development for reuse is referred to as Domain Engineering.5 Development with reuse, on the other hand, is referred to as Application Engineering.

  • Source location: Section 3, “System Family Approach,” page 3

  • Source extract (verbatim): Domain Analysis involves domain scoping and feature modeling. Domain scoping determines which systems and features belong to the domain and which not. This process is driven not only by technical but also marketing and economic aspects (i.e. there is an economic analysis as in the case of any investment) and involves all the stakeholders of the domain. For this reason, the resulting domain is often referred to as a product line. Feature modeling identifies the common and variable features of the domain concepts and the dependencies between the variable features. Refining the semantic contents of the features usually requires several other modeling techniques such as modeling relationships and interactions between objects (e.g. using UML).

  • Source location: Section 3, “System Family Approach,” page 3

  • Source extract (verbatim): The purpose of domain design is to develop a common architecture for the system family.

  • Source location: Section 3, “System Family Approach,” page 3

  • Source extract (verbatim): Domain Implementation: Finally, we need to implement the components, generators, and the reuse infrastructure (dissemination, feedback loop from application engineering, quality control, etc.).

  • Source location: Section 3, “System Family Approach,” page 3

  • Source extract (verbatim): Once we have the architecture, we can implement the components. As stated, a component from a given layer takes a component from the layer below it as a parameter, i.e. we need to implement the components as parameterized components.

  • Source location: Section 5.3, “Implementation Components,” page 9

  • Source extract (verbatim): Once we have the “right” components, the next step is to provide means of mapping abstract requirements onto appropriate configurations of components, i.e. automate the component assembly. The key to this automation is the configuration knowledge, which maps between the problem space and the solution space (Fig. 1).

  • Source location: Section 4, “Problem vs. Solution Space and Configuration Knowledge,” page 4

  • Source extract (verbatim): Finally, the configuration knowledge is implemented using generators. Depending on the complexity of the configuration space, the configuration process may be an algorithmic one (for simple configuration spaces) or search-based (for more complex configuration spaces).

  • Source location: Section 4, “Problem vs. Solution Space and Configuration Knowledge,” page 5

  • Source extract (verbatim): The generator takes a specification of a system or component and returns the finished system or component.

  • Source location: Section 5.6, “The Generator,” page 11

Connections Found

This paper is a historical technical anchor for symbolic computational production within a supplied family model. It compares with Learning inside a fixed decomposition inherits its mistakes: configuration knowledge fixes the valid requests, defaults, dependencies, and mappings through which the generator can act, so automating assembly does not expand the family model. It also compares with The bitter lesson selects production methods, not representational forms: production is computational at the family-member level, but the architecture, components, configuration knowledge, and generator are hand-designed. It is evidence for A hand-crafted bootstrap fits the Bitter Lesson only if learning can outgrow it by identifying the family-specific structures that a domain-extensible successor would need to construct and retain rather than merely consume. The paper's brief reuse-infrastructure feedback loop is not a demonstrated learning-and-retention transition.

Extractable Value

  1. Separate family engineering, member configuration, and member generation. The source gives the lineage for three operations that later factory theory should not collapse: defining the production space, selecting a point in it, and automatically materializing that selection. None by itself constructs a retained successor production system. [quick-win]
  2. Treat configuration knowledge as the explicit boundary of automatic generation. Illegal combinations, defaults, derived defaults, construction rules, and optimizations mediate between the problem-space request and the solution-space components. This makes the generator computational without making its admitted distinctions or mappings learned. [quick-win]
  3. Preserve the source's extensibility nuance. Its specification language may range from high-level requests to implementation details and user-supplied components. Generation inside a supplied family can therefore expose extension points; the decisive boundary is who constructs and revises the family model and production machinery, not whether callers have any local freedom. [deep-dive]
  4. Use active libraries as prior art for executable localized production machinery. The paper places metacode beside domain abstractions so a library can generate, specialize, optimize, configure, or check code. This supports the possibility of symbolic production machinery while supplying no evidence that experience learns or replaces that machinery. [just-a-reference]
  5. Keep the reported applications as feasibility examples, not comparative evidence. The matrix, factorization, and postal-automation libraries show that the proposal was intended beyond the car example, but the paper does not evaluate their production process against alternatives. [just-a-reference]

Limitations (our opinion)

Our opinion: the paper establishes a design vocabulary and demonstrates a toy implementation, but it does not run a controlled comparison of manual assembly, generative assembly, or alternative family models. Its larger applications are brief reports without measurements of engineering cost, maintenance, correctness, break-even conditions, or failure modes. The manufacturing analogy can therefore overstate what automation establishes: the domain scope, feature distinctions, architecture, component inventory, configuration rules, and generator are assumed to be successfully engineered. As Learning inside a fixed decomposition inherits its mistakes makes explicit, successful construction within those choices does not test excluded decompositions. The active-library discussion is a forward-looking platform proposal, and the mentioned feedback loop from application engineering does not specify computational proposal, evaluation, or operative retention. The paper therefore cannot support a claim that use constructs family-specific production machinery or retained successor factories.

Write one foundations note titled “Automatic product generation is not factory learning” that uses this paper's three-level distinction—family engineering, member configuration, and member generation—to define the additional proposal, evaluation, and operative-retention transition required for a system to construct and keep successor production machinery.

Abstracted into: