1 Semantics
1.1 Abstract Syntax
Features, types and constraints.
Let Id be a finite set of features, let Kinds be a set of domainspecific feature kinds and let Flavors be a set of types that further define a feature’s possible values. More precisely, package, component, option, interface and . Furthermore, we introduce two types of expressions allowed in CDL: Goal expressions and list expressions.
Concerning the first one, we define to be a set of goal expressions over Id, generated by the following grammar:
(1) 
Here, , , , {get_data, is_active, is_enabled, is_loaded, is_substr, is_xsubstr, version_cmp}, and , whereas Data is a set of untyped data (say all character strings).
The second type of expressions, socalled list expressions represent an enumeration of values or ranges, which can be computed by goal expressions. Thus, we define to be a set of list expressions over goal expressions, generated by the following grammar ():
(2) 
CDL models.
Cdl is the set of all possible models in CDL. Each CDL model is a set of nodes, so , where
(3) 
If , then is the name, is the parent of the node ( for nodes at the top level), is a set of active_if visibility goal expressions, and is a set of requires goal expressions. Further, denotes a calculated goal expression that prescribes the feature’s values and is a legal_values list expression restricting its values. Finally, specifies the node’s domainspecific kind and specifies whether the node implements one or more interfaces. There is no further restriction on both values, that is, an interface can even implement other interfaces. We write to denote names of nodes in the model , so .
Wellformedness.
CDL introduces some more constraints on the syntax of the model. If
, it has to fulfill the following invariants:

(calculated has no effect if flavor is none)

(calculated and legal_values exclude each other)

(legal_values applies to nodes with nonfixed data value only, see Eq.4)

(Interfaces must neither have the none flavor nor a calculated property)

The parent relationship should define a tree, with the virtual as the root. Furthermore, nodes of kind option must not be parents of other nodes.
Preprocessing notes.
For convenience and conciseness reasons, the abstract syntax given in this section depends on the following preprocessing steps from the concrete syntax:

Similar to the configuration tool, we introduce a synthetic root element , which is a parent to every toplevel package.

In case no flavor is specified for a node, we set the flavor () property (according to the CDL documentation) to booldata for packages, to bool for components and options, and to data for interfaces.

The requires, active_if and calculated properties can contain an enumeration of goal expressions separated by whitespace. We convert such enumerations to a disjunction of their goal expressions.
1.2 Semantic Domain
A configuration is an assignment of triples of values to nodes. The set of all possible configurations is:
(4) 
If and , we write for the first component of the valuation (the enabled state), for the second one (the enabled value), and for the third component of the valuation (the data value). The first component specifies whether the node is actually in the configuration, that is, whether it influences the build of eCos in some sense. The latter two components refer to values the user can give to a node. We predefine the valuation of the element as follows: .
Now, a semantics of a CDL model is given in terms of sets of configurations, so is our semantic domain and the semantic function has the signature:
(5) 
(6) 
1.3 Semantics
Helper functions.
Let denote a function that returns the value of a feature under a certain configuration while taking its enabled state into account.
(7) 
Since arbitrary values can be returned for a feature’s occurrence in an expression, and since they can be direct input to Boolean operators (e.g., “feature A requires B && C” and C could have flavor data or booldata), we define a cast of arbitrary values to Boolean values in the TCL/TK style. More precisely, . Please note that bool is also defined for plain Boolean values (), which are the return type if nodes are inactive, disabled, or bool.
(8) 
For the evaluation of goal expressions, we define the function recursively as follows, with , and :
(9) 
We left out CDL’s builtin functions (see Func in 1.1) in the definition of eval and refer to the CDL online documentation instead.
For the evaluation of values against the legal_values property, we introduce a satisfaction relation . For , we define the relation:
(10) 
Semantic function.
The semantics of a model is just an intersection of denotations of all the nodes except that we need to ensure that all the unloaded packages (that is, their nodes) are enforced to be false. Furthermore, we adhere to the semantics of the nodes’ flavor as well as we take their calculated/legal_values property and the interface concept into account.
(11) 
The semantics of a node is a set of all configurations that (1) contain the node’s parent, (2) have the node’s enabled value set, and (3) can satisfy the node’s constraints. Notably, we ignore the unloaded packages here, as we treated them all globally above (here ’unloaded’ = ’not mentioned in the model’). For brevity, we also introduce a macro for crosstree constraints: .
(12) 
Next, we continue with the denotation of nodes according to their flavor property. The values none and data are the equivalent to mandatory features in Feature Modeling (FM) with one big difference: In CDL, such nodes can be made optional with crosstree constraints, whereas in FM, crosstree constraints of mandatory features also constrain the parent. In the flavor denotation, we set the enabled value for none and data features. With regard to Eq. 12, such mandatory nodes still require the parent node present and crosstree constraints satisfied.
(13) 
The calculated property forces a node’s data and enabled value depending on the flavor. Please note that CDL excludes the none flavor for calculated nodes (cf. Sec. 1.1, wellformedness). For , we define:
(14) 
The legal_values property restricts the data value of a node with a list expression. We define its denotation by using our satisfaction relation from Eq. 10. Interestingly, the legal_values property only excludes the flavor bool by wellformedness rules (cf. Sec. 1.1), whereas it does not have any effect on noneflavored nodes. For , we define:
(15) 
Finally, we specify the denotation of interfaces, which represent derived features in CDL. However, please note that the none flavor is excluded by wellformedness rules (cf. Sec. 1.1).
(16) 
where is defined as follows:
(17) 
2 Propositional Semantics
We now describe a Boolean interpretation of the abstract syntax. Given CDL’s expressiveness, there is no precise translation from a CDL model into propositional logic. While it is relatively easy to translate the hierarchy and flavor constraints into a propositional formula, this task becomes more complicated for crosstree constraints and the interface concept. Our strategy is to approximate constraints as much as possible by loosening the original constraints, that is, the propositional semantics underapproximate the full ones.
We tailor the full semantics down to denotations that can be expressed in propositional logic. Based on these semantics, we implemented^{3}^{3}3https://code.google.com/p/variability/wiki/CDLTools rewriting rules that take a full CDL model and convert it into a Boolean formula, enabling analysis based on SAT solvers. The latter comprises, for instance, satisfiability and dead feature checks, or building implication graphs.
2.1 Propositional Semantic Domain
We define
(18) 
If and , we write for the valuation of the node under a configuration. We also predefine for the element. Similar to the full semantics, the propositional semantics of a CDL model is given in terms of sets of configurations, so is our semantic domain. Thus, our semantic function has the following signature:
(19) 
Furthermore, we define some invariants between the full (Confs) and propositional () configuration spaces, basically answering the question: What does it mean if a feature under a Boolean configuration is true or false with regard to the full semantics ? Table 1 shows the invariants according to a node’s flavor.
Flavor  Invariant 

bool  
none  
booldata  
data 
2.2 Propositional Semantics
Helper functions.
A function such as is not necessary anymore, since a node does only have one value left (that is, ). However, a slightly different function will be helpful later in this section:
(20) 
Boolean expressions.
We just have to consider goal expressions since list expressions only appear in legal_values constraints, which cannot be approximated^{4}^{4}4One could argue that it is possible to approximate special cases, such as legal_values 0 and so on. However, it would spoil our translation with too many exceptions and we have not seen comparable examples in the real models. in the propositional semantics since our semantic domain contains no data value any more. Let be a subset of Boolean expressions over Id, which is defined by the following grammar, with and :
(21) 
Boolean expression evaluation.
The evaluation of BExp(Id) now follows ordinary propositional semantics. Thus, the definition of a function is pretty straightforward, with , and :
(22) 
Expression rewriting rules.
Next, we define a partial function rewrite:, which translates goal expressions from the full semantics to reduced Boolean ones. For , and :
(23) 
For the interpretation of interfaces, we need to define a helper function . More precisely, converts a set of Ids into a Boolean expression, where at least min and at most max Ids can be satisfied simultaneously.
For and if denotes an interface, we continue the definition of rewrite as follows:
(24) 
Semantic function
The propositional semantics of a model is just an intersection of the propositional denotations of all the nodes, similar to the full semantics. However, we (have to) leave out legal_values as already pointed out. Furthermore, we need some more context (the current model ) for the rewrite function, since our propositional semantic domain is not capable of carrying enough information any more.
(25) 
The semantics of a node is a set of all configurations that can satisfy its constraints. For the propositional version, we introduce the macro .
(26) 
We continue with the denotation of nodes according to their flavor property:
(27) 
Similarly, we define the denotation of the calculated property. For :
(28) 
Finally, the propositional denotation of interfaces can be declared as follows:
(29) 
References
 [1] (2012) Variability modeling in the systems software domain. Technical report Technical Report GSDLABTR 20120706, Generative Software Development Laboratory, University of Waterloo. Note: Available at http://gsd.uwaterloo.ca/tr/vm2012berger Cited by: Formal Semantics of the CDL Language Technical Note.
 [2] (2010) Variability modeling in the real: a perspective from the operating systems domain. In International Conference on Automated Software Engineering (ASE), Cited by: Formal Semantics of the CDL Language Technical Note.