Formal validation of domain-specific languages with derived features and well-formedness constraints

Abstract

Despite the wide range of existing tool support, constructing a design environment for a complex domain-specific language (DSL) is still a tedious task as the large number of derived features and well-formedness constraints complementing the domain metamodel necessitate special handling. Such derived features and constraints are frequently defined by declarative techniques (such graph patterns or OCL invariants).However, for complex domains, derived features and constraints can easily be formalized incorrectly resulting in inconsistent, incomplete or ambiguous DSL specifications. To detect such issues, we propose an automated mapping of EMF metamodels enriched with derived features and well-formedness constraints captured as graph queries in EMF-IncQuery or (a subset of) OCL invariants into an effectively propositional fragment of first-order logic which can be efficiently analyzed by back-end reasoners.On the conceptual level, the main added value of our encoding is (1) to transform graph patterns of the EMF-IncQuery framework into FOL and (2) to introduce approximations for complex language features (e.g. transitive closure or multiplicities) which are not expressible in FOL. On the practical level, we identify and address relevant challenges and scenarios for systematically validating DSL specifications. Our approach is supported by a tool and it will be illustrated on analyzing a DSL in the avionics domain. We also present initial performance experiments for the validation using Z3 and Alloy as back-end reasoners.

Evaluating Well-Formedness Constraints on Incomplete Models

“…In this paper, domain models are captured by the Eclipse Modeling Framework (EMF) [36], which is frequently used in industrial modeling tools. An extract of metamodel for Yakindu statecharts describing the state graph is illustrated in Figure 2 Metamodel elements are mapped to a set of logic relations as defined in [32,20], which are revisited below:…”

“…Further structural restrictions implied by a metamodel (and formalized in [32]) include (1) Generalization (GEN), which expresses the fact that a more specific (child) class has every structural feature of the more general (parent) class, (2) Type compliance (TC) requires that for any relation R(o, t), its source and target objects o and t need to have compliant types, (3) Abstract (ABS): If a class is defined as abstract, it is not allowed to have direct instances, (4) Multiplicity (MUL) of structural features can be limited with upper and lower bounds in the form of "lower..upper" and (5) Inverse (INV), which states that two parallel references of opposite direction always occur in pairs. Finally EMF instance models are often expected to be arranged into a containment hierarchy, which is a directed tree along references marked in the metamodel as containment (e.g.…”

“…Model M is a valid instance of a metamodel Meta (denoted by M |= Meta) if (i) all classes, references and attributes are defined in Meta and (ii) satisfies the structural constraints (1) − (5) [32].…”

“…Our technique uses the partial snapshots [32] to represent incomplete partial models, and it is compatible with EMF (Eclipse Modeling Framework) [36] which is the de facto industrial modeling standard in MDD. Wellformedness constraints are captured as graph queries using the pattern language of Viatra [4].…”

Ensuring Correctness of Model Transformations While Remaining Decidable

“…Viatra tool has similar model checking capabilities [25] and in addition allows the verication of elaborate well-formedness constraints imposed on models [23].…”