Log In Sign Up

Formal Semantics of the CDL Language

We reverse-engineer a formal semantics of the Component Definition Language (CDL), which is part of the highly configurable, embedded operating system eCos. This work provides the basis for an analysis and comparison of the two variability-modeling languages Kconfig and CDL. The semantics given in this document are based on analyzing the CDL documentation, inspecting the source code of the toolchain, as well as testing the tools on particular examples.


page 1

page 2

page 3

page 4


A Component-Based Formal Language Workbench

The CBS framework supports component-based specification of programming ...

A Formal Semantics of Findel in Coq (Short Paper)

We present the first formal semantics of Findel - a DSL for specifying f...

Formal Semantics of the Kconfig Language

The Kconfig language defines a set of symbols that are assigned a value ...

One Down, 699 to Go: or, synthesising compositional desugarings

Programming or scripting languages used in real-world systems are seldom...

Formal Description of Components in Operating Systems

The contemporary development of hardware components is a prerequisite fo...

Quantifiers metamorphoses. Generalizations, variations, algorithmic semantics

This article contains ideas and their elaboration for quantifiers, which...

Towards Conceptual Modeling Semantics: Eventizing Tarski's Truth Schema

Modeling languages in software engineering (e.g., UML) evolved from soft...

1 Semantics

1.1 Abstract Syntax

Features, types and constraints.

Let Id be a finite set of features, let Kinds be a set of domain-specific 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:


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, so-called 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 ():


CDL models.

Cdl is the set of all possible models in CDL. Each CDL model is a set of nodes, so , where


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 domain-specific 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 .


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 non-fixed 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.

Pre-processing notes.

For convenience and conciseness reasons, the abstract syntax given in this section depends on the following preprocessing steps from the concrete syntax:

  1. Similar to the configuration tool, we introduce a synthetic root element , which is a parent to every top-level package.

  2. 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.

  3. 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:


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:


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.


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.


For the evaluation of goal expressions, we define the function recursively as follows, with , and :


We left out CDL’s built-in 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:


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.


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 cross-tree constraints: .


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 cross-tree constraints, whereas in FM, cross-tree 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 cross-tree constraints satisfied.


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, well-formedness). For , we define:


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 well-formedness rules (cf. Sec. 1.1), whereas it does not have any effect on none-flavored nodes. For , we define:


Finally, we specify the denotation of interfaces, which represent derived features in CDL. However, please note that the none flavor is excluded by well-formedness rules (cf. Sec. 1.1).


where is defined as follows:


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 cross-tree 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 under-approximate the full ones.

We tailor the full semantics down to denotations that can be expressed in propositional logic. Based on these semantics, we implemented333 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


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:


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
Table 1: Invariants between configuration spaces

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:


Boolean expressions.

We just have to consider goal expressions since list expressions only appear in legal_values constraints, which cannot be approximated444One 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 :


Boolean expression evaluation.

The evaluation of BExp(Id) now follows ordinary propositional semantics. Thus, the definition of a function is pretty straightforward, with , and :


Expression rewriting rules.

Next, we define a partial function rewrite:, which translates goal expressions from the full semantics to reduced Boolean ones. For , and :


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:


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.


The semantics of a node is a set of all configurations that can satisfy its constraints. For the propositional version, we introduce the macro .


We continue with the denotation of nodes according to their flavor property:


Similarly, we define the denotation of the calculated property. For :


Finally, the propositional denotation of interfaces can be declared as follows:



  • [1] T. Berger, S. She, R. Lotufo, A. Wasowski, and K. Czarnecki (2012) Variability modeling in the systems software domain. Technical report Technical Report GSDLAB-TR 2012-07-06, Generative Software Development Laboratory, University of Waterloo. Note: Available at Cited by: Formal Semantics of the CDL Language Technical Note.
  • [2] T. Berger, S. She, R. Lotufo, A. Wasowski, and K. Czarnecki (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.