The Prisma project uses Xtext (2017) as a language workbench for the various domain specific languages. Xtext is very powerful and supports almost all features described in
the feature model of Erdweg et al. (2013) with an editor generated based on the popular Eclipse platform.
Xtext can in a sense be seen as a combination of traditional compiler tools and the notion of language workbenches. Specifying a domain specific language in Xtext follows a similar process as traditional compiler construction. Xtext however also uses part of these specifications to customize the supporting editor while providing many hooks to override or extend this customization.
Development of a domain specific language in Xtext is often characterized as a three stage process: (1) write a grammar for the language, (2) customizing validation and (3) developing a code generator or interpreter.
6.4.1 Writing a Grammar
The syntax, and to a lesser extent the semantics, of a domain specific language in Xtext are defined in its grammar. From the grammar, both a lexer and a parser are generated. Rules for the lexer are denoted by the terminal keyword and match certain streams of input to so-called tokens. The other rules match these tokens to produce the abstract syntax tree of a DSL instance. To aid in the creation of these grammars, Xtext provides some inheritance features and corresponding libraries. These libraries range from a set of simple terminal rules (for integers, strings, comments etc.) to a more fully fledged expression language called XBase.
As its abstract syntax tree, Xtext uses models as defined in the Eclipse Modeling Framework.3 Xtext automatically infers ametamodel in Ecore format from a grammar.
This metamodel defines the structure of a language, for example modeling that a Building has Floors which have Rooms, etc. A parsed instance of a domain specific language is then an instance of this metamodel, for example, that the Building “OfficeBuilding” has floors “Floor1” and “Floor2” which contain six and seven rooms, respectively. EMF can then map nodes in the metamodel to Java classes, and the instance of this metamodel to instances of these Java classes. While similar to providing a custom-generated abstract syntax tree, this metamodeling approach allows Xtext to reuse large parts of EMF and in turn, also allows interoperability between Xtext and EMF.
6.4.2 Customizing Language Validation
Xtext aims to do as much automatic validation as possible but offers to customize much of this behavior. Xtext does automatic syntactic validation before producing an abstract syntax tree but also does semantic validation. Validation can be extended using the following methods:
Check methods Xtext provides a framework to execute small checks on parts of the
AST. The functions in this class that are decorated with the@Checkannotation are automatically called with the relevant subtree of an AST. These validation steps are stateless, for example, checking whether a variable was defined before it was
accessed involves finding all previously defined variables and concluding that the currently evaluated variable is one of these.
Linking Xtext has built-in linking. It is possible to reference any element from any rule.
For example, when modeling a BuildingComplex consisting of Buildings, Xtext can cross-link between parts of the AST that define buildings, and parts that define the encompassing building complex.
Scoping Xtext allows defining what is considered linkable in a given context. Variables
in programming languages can typically only be used in expressions when they have been defined before. Top-level functions, however, can (in the case of Java) be called from any point in a class, whether they are defined before or after their reference. To determine whether linking is semantically correct, the Xtext linking provider will consult the scoping provider. This scoping provider yields a list of reachable declarations for the given point in the program and can be extended to support block scoping, namespacing, import and exports, etc.
Xtext argues that these verification hooks are sufficient to establish whether an instance of a DSL is semantically correct.
6.4.3 Code Generation and Interpreting
Xtext mainly focuses on code generation. Every project created with Xtext comes with a (stub) class that can be used to generate code. The doGenerate method of this class
is automatically called by the framework when changes in the files are detected and all validation steps have passed. The implementation of this method is then responsible for correctly outputting generated code for the passed abstract syntax tree.
Interpreting is not directly implemented in Xtext but can be achieved by recursively traveling the abstract syntax tree, an interpreter can be created as a standalone program that parses/checks/interprets a particular domain language instance and produces output as a result. Integration of this interpreter into the generated editor is possible by the flexible nature of Eclipse, but not by default supported by Xtext. There is no API to map the “run” button of the generated language tools to the execution of an interpreter on the selected domain specific language instance.
Part III
Part Outline
In this part of the report, we will outline the steps taken to create a Query language not only for the lighting domain but a framework for a Query language for any domain. This part is split in seven chapters:
Chapter 7 discusses the considerations that required reformulating the research ques-
tions shown in the precursor (research topics) report. The chapter lists the new research questions and outlines the new approach taken for Query language cre- ation.
Chapter 8 outlines the generic base for the Query language and discusses the steps
required to instantiate this generic base for a new domain.
Chapter 9 shows the instantiation of the generic Query language specifically for the
lighting domain. This chapter lists the patterns, scopes, atomic propositions and composite operators that we have selected for lighting system property specification.
Chapter 10 shows the concrete syntax of the Query language for the lighting domain as
well as its static semantics. Furthermore, it outlines how some of the syntactic sugar of the concrete syntax can be represented in just propositions and (instantiated) pattern/scope combinations.
Chapter 11 discusses the need for a new translation of pattern libraries to support both
formal verification and simulation. We show a variation on the translation to timed automata by Gruhn and Laue (2006) in the form of monitors and rules, show
an example translation of a pattern for all scopes and show possible semantical alterations of pattern/scope combinations that can be achieved using the extended translation.
Chapter 12 shows how the framework of monitors and rules is implemented in UP-
PAAL. Furthermore, it shows how propositions, both atomic and composite, are implemented in the UPPAAL model.
Chapter 13 shows how the framework of monitors and rules is implemented in the Co-
simulation Framework. Furthermore, it shows how propositions, both atomic and composite, are implemented in the Co-simulation Framework.
7 Design Considerations
A Query language like ours is the product of countless hours of discussions, brainstorms and mental processing. As with any research, the initial plan of development was very different from the delivered product. The initial research questions, also outlined in the (predecessor) research topic report (Buit (2017)), were as follows:
Original Research Question Can we create a domain specific language for the lighting
domain and approach by TNO-ESI in which various stakeholders can capture light- ing properties that are formally verifiable and align with the technical knowledge of these stakeholders both in property specification and in conveying error?
Original Subquestion 1 Who is the intended user of the proposed Query language, what
questions do these stakeholders have and can we group these questions in mean- ingful categories?
Original Subquestion 2 What types of formalisms do we need to cover the needs from
various stakeholders, can we use known theories of property specification using pattern/scope combinations?
Original Subquestion 3 How can we map the set of queries with the chosen formalisms
to an easily understood DSL that integrates well with the existing framework of DSLs, is useful to the stakeholders, and can be extended with ease?
These questions remain relevant to creation of a Query language specifically for the lighting domain, but proved infeasible to tackle in during the research period. This chapter outlines the considerations that required reformulating the research questions, lists the new research questions and ends with the new approach.
7.1 Consideration: The Value of Abstraction
In initial discussions about creation of a Query language with potential stakeholders of Philips Lighting we were confronted with a wide variety of viewpoints. We had prepared some example properties and openly discussed these with testers and architects of Philips Lighting. These example properties (implicitly) assumed a system wide view. This as- sumption came from the way a lighting system is designed using the Prisma methodology: a lighting system starts as a specification of its behavior, its environment and its mapping to the physical devices and is then “compiled” to configuration for hardware products (of Philips Lighting). This methodology aligns well with the new business model of Philips Lighting: selling “Lighting as a Service”.
The view of Prisma is technology independent. Many potential stakeholders in the Query language are used to thinking in terms of appliances. This confronted us with a fundamental challenge: discussing system wide properties is not always trivial as not every stakeholder is used to abstract from the intricate details of physical appliances. This abstraction is crucial to the domain model of the Prisma project. The proposed domain modeling approach hides complexities of particular technologies and reduces lighting systems to their core: behavior of lighting systems and possible influence of its environment. Details of particular technologies are only introduced when required. A Query language can only reason about concepts known in the domain model and is therefore limited to the abstracted view. In these discussions with stakeholders we often had to discuss the domain approach and its abstractions first before discussing potential properties specified using the Query language. Obtaining valuable input for the Query language proved challenging as not all stakeholders in the lighting domain had already embraced the domain approach.
While we could have concluded that creation of the Query language should be deferred to when the domain modeling approach of the Prisma project has been adopted thor- oughly by stakeholders of Philips Lighting we believe that the Query language is a strong argument for its adoption. One of the largest benefits of a domain approach is the ability to analyze a lighting system prior to implementation. The proposed Query language allows to record properties in a structural manner and is crucial in this early validation. Our focus shifted from creating a Query language specifically for Philips Lighting to the creation of a prototype to show the potential of early validation. Once the domain approach is well integrated within Philips Lighting, the prototype can be extended and tuned specifically for the lighting domain.