• Variability modeling. A core principle is variability modeling, which explicitly describes the differences among the systems in a product line. This description includes basic incompatibilities—certain system characteristics cannot be present simultaneously. Typical approaches for variability modeling are feature models or decision models. 4
• Reference architecture. A reference architecture is more than a standard software architecture—because it provides explicit customizations that cover the entire product line, it supports the variations described by the variability model.
• Business scoping. Product line design requires understanding that the architecture addresses an entire domain or business field, not just a single customer or project.
• Two life cycles. A conceptual distinction is made between the development of capabilities for reuse, which must be generic and easily composable to several different systems, and development with reuse, which aims to create products from the assets created in the for-reuse life cycle.
• contains an explicit representation of the configuration space and constraints that describe permissible runtime reconfigurations on the level of intended capabilities of the system (as opposed to a technical level). This is a variability model in the sense that discrete options are identified (as opposed to continuous models). This differentiates a DSPL clearly from several other adaptation approaches.
• can perform the necessary system reconfiguration autonomously. Thus, once the intended configuration is known, the derivation of different system instances must be autonomous. Environmental monitoring and subsequent identification of a desired configuration are not explicitly necessary to qualify as a DSPL.
• is developed based on an engineering process that explicitly takes the variability scope into account. Thus, DSPL engineers can exploit "classic" SPL engineering principles and approaches.
• It need not be built as part of an SPL. This may seem puzzling at first, but it simply means the entire variability can be managed at runtime.
• Its variability model at least implicitly predefines its adaptation space. Because variability models are discrete models, any problem requiring some form of analogous or continuous modeling is not appropriate for them.
• A purely parameterized adaptation is not considered a DSPL; rather, a modification of the actually executing system implementation is required. Ideally, the architectural components are reconfigured.
• It does not need to be self-adapting. It is completely valid for a human to make a decision on the abstract level to perform a reconfiguration. However, the DSPL must manage all aspects of realizing this reconfiguration at runtime, without human intervention.
• Thus far, little support exists for DSPL evolution. Successful evolution requires approaches that explicitly exploit and leverage DSPL characteristics, which could include automated (learning-based) evolution.
• Although approaches to the implementation of development-time configuration are well-understood, DSPL approaches for runtime reconfiguration remain an important research area, especially with respect to their relation to the overall system architecture.
• While the core variability model focuses on modeling the reconfiguration options, ongoing DSPL research attempts to enlarge these approaches to capture context description and decision making.
• Similar to classic product line engineering, DSPL reconfiguration has focused mainly on functional capabilities, while addressing quality characteristics to only a limited extent.
• Dealing with overly constrained situations at runtime remains a concern. For example, although several available capabilities might be required simultaneously, the variability model defines them as mutually exclusive.
• An additional concern is how to best extend variability modeling so that developers can use it as a basis for context interpretation and thus support the fully autonomous case.