Contextual constraints in configuration languages Dennis Wagelaar Vrije Universiteit Brussel System and Software Engineering Lab Pleinlaan 2, 1050 Brussels, Belgium dennis.wagelaar@vub.ac.be 1. Introduction Configuration languages are a very common solution to manage the variability in software systems. They can take the form of product models for software product lines [6], configuration files for software frameworks 1 , workflows for program generators 2 as well as configuration models that are built into the software and can be changed at run- time [3]. Configuration languages can be defined in a va- riety of ways, ranging from grammars to XML schemas and meta-models. Often, a configuration language defines a number of constraints that rule out any inconsistent config- urations. These constraints can be part of the language def- inition [4] or they can be defined separately [1]. The scope of such constraints is typically limited to so-called interac- tion constraints, which describe what configuration options can be combined with each other. This limit is caused by the vocabulary with which the constraints have to be expressed. This vocabulary is of course only scoped to express the pos- sible configurations. Another kind of constraint that can apply to configura- tions, is a contextual constraint. Contextual constraints refer to the context in which a software system must work. The relationship between context and programming is described in Context-Oriented Programming [5]. We believe that, in order to describe constraints based on context for a configu- ration language, there must be an explicit vocabulary of this context. These contextual constraints can then be bound to the configuration language by relating them to the configu- ration language definition (grammar, schema, meta-model, ...). Ontologies have proven to be a suitable format for describing the concepts that can occur in the con- text [11][8][7]. The standard ontology language OWL [10] provides a way to reason about ontologies with descrip- tion logic using the OWL DL variant. We have shown in 1 http://www.hibernate.org/hib_docs/reference/ en/html/session-configuration.html 2 http://www.openarhictectureware.org/ previous work that it is possible to express platform con- cepts and platform dependency constraints in OWL DL [14], where platform represents a part of the con- text for a software system. We believe that it is possible to generalise this approach to context and context con- straints. In the rest of this paper, we discuss briefly how con- text and context constraints can be expressed in OWL DL. We then illustrate how context constraints can be integrated with a configuration language. Finally, we conclude this pa- per with a summary. 2. Using OWL DL for context In order to express context constraints, we define an ex- plicit ontology of the context concepts we want to reason about. This ontology is used as a basis to express the cur- rent context as well as context constraints. Because the cur- rent context and the context constraints use the same con- text ontology, an automatic inference engine can determine which context constraints are satisfied by the context. We represent context constraints in OWL as classes. As an ex- ample of context and context constraints, we will use plat- forms and platform dependency constraints, respectively. Consider, for example, the “JavaAWTPlatform” platform dependency constraint shown in Fig. 1. Platform JavaAWTPlatform isa = necessary ≡ ∃ providesSoftware JavaAWTLibrary = necessary-and-sufficient Figure 1. Example platform dependency “JavaAWTPlatform” is represented as an OWL class with a necessary constraint as well as a necessary-and- sufficient constraint. Whereas it is necessary that each