Simon Van Mierlo

Integrating a neutral action language in a DEVS modelling environment

Visual environments for the modelling and simulation of complex, software-intensive systems are increasingly popular. While visual languages have many advantages, they may not be appropriate to render all details of a Discrete EVent system Specification (DEVS) model. Textual may be more appropriate, both to completely describe all details of a DEVS model (i.e., the content of transition and output functions), and to make the specification independent of the implementation platform (i.e., simulation implementation language). In this paper, we propose two textual notations that are used as part of an integrated modelling and simulation environment for the Parallel DEVS formalism. Both notations allow the specification of DEVS functions by means of neutral action code. DEVSPro uses Python-like textual syntax and supports the full power of Parallel DEVS. From this neutral specification, simulator-specific code is synthesized. DEVSLang supports blended textual/visual modelling. It is more restricted in expressiveness to match the limited expressiveness of visual notations. For example, the sequential states in an Atomic model must be explicitly enumerated. Visual DEVSLang models are transformed to their textual form in order to carry out syntactic and semantic checks. Possible detected errors are fed back to the visual modelling environment allowing the modeller to make changes directly in the source model. DEVSLang models are further translated automatically to DEVSPro models to allow for possible combination with DEVSPro models and subsequent analysis and simulation.

Adding Rule-Based Model Transformation to Modelling Languages in MetaEdit+

MetaEdit+is a commercial tool by MetaCase for creating domainspecific, syntax-directed visual modelling environments. MetaEdit+synthesizes such environments from user-provided metamodels and contains a Generator Editor for code/report generation. An API is provided to allow external manipulation of models through SOAP. Currently, the MetaEdit+ tool does not natively support rule-based model-to-model transformation. Such transformations are useful as they allow domain experts to intuitively (using domain-specific notations) model either operational semantics (a simulator) or denotational semantics (through model-tomodel transformation onto a model in a known formalism) of a modelling language. We will demonstrate how to add rule-based operational semantics to modelling languages in MetaEdit+. In our approach, transformation rules are visually created in MetaEdit+. The rule editor is synthesized using modified versions of the original language’s metamodel. This modification is performed in a structured fashion using a process called RAMification. Both the model and the rules are exported from MetaEdit+ to Python code. This code is combined with Py-T-Core, our library of transformation language primitives, to apply the rules on the model. Our demonstration has a client-server architecture, with the MetaEdit+ visual modelling environment as the client and the transformation engine as the server. After each transformation step, in-place changes to the model are propagated to MetaEdit+ for visualization using the SOAP API. A simple (manufacturing) Production System modelling language is used as an example.

Concrete syntax: a multi-paradigm modelling approach

Domain-Specific Modelling Languages (DSLs) allow domain experts to create models using abstractions they are most familiar with. A DSLs syntax is specified in two parts: the abstract syntax defines the languages concepts and their allowed combinations, and the concrete syntax defines how those concepts are presented to the user (typically using a graphical or textual notation). However important concrete syntax is for the usability of the language, current modelling tools offer limited possibilities for defining the mapping between abstract and concrete syntax. Often, the language designer is restricted to defining a single icon representation of each concept, which is then rendered to the user in a (fixed) graphical interface. This paper presents a framework that explicitly models the bi-directional mapping between the abstract and concrete syntax, thereby making these restrictions easy to overcome. It is more flexible and allows, amongst others, for a model to be represented in multiple front-ends, using multiple representation formats, and multiple mappings. Our approach is evaluated with an implementation in our prototype tool, the Modelverse, and by applying it on an example language.

Domain-Specific Modelling for Human–Computer Interaction

Model-driven engineering (MDE) is an important enabler in the development of complex, reactive, often real-time, and software-intensive systems, as it shifts the level of specification from computing concepts (the “how”) to conceptual models or abstractions in the problem domain (the “what”). Domain-specific modelling (DSM) in particular allows to specify these models in a domain-specific modelling language (DSML), using concepts and notations of a specific domain. It allows the use of a custom visual syntax which is closer to the problem domain and therefore more intuitive. Models created in DSMLs are used, among others, for simulation, (formal) analysis, documentation, and code synthesis for different platforms. The goal is to enable domain experts, such as a power plant engineer, to develop, to understand, and to verify models more easily, without having to use concepts outside of their own domain. The first step in the DSM approach when modelling in a new domain is, after a domain analysis, creating an appropriate DSML. In this chapter, we give an introduction to DSML engineering and show how it can be used to develop a human–computer interaction interface. A DSML is fully defined by its syntax and semantics. The syntax consists of (i) the abstract syntax, defining the DSML constructs and their allowed combinations, captured in a metamodel, and (ii) the concrete syntax, specifying the visual representation of the different constructs. The semantics defines the meaning of models created in the domain. In this chapter, we show how two types of semantics (operational and translational) can be modelled using model transformations. Operational semantics gives meaning to the modelling language by continuously updating the model’s state, effectively building a simulator. Translational semantics defines mappings of models in one language onto models in a language with known semantics. This enables the automatic construction of behavioural models, as well as models for verification. The former can be used for automated code synthesis (leading to a running application), whereas the latter leads to model checking. We choose to specify properties for model checking using the ProMoBox approach, which allows the modelling of properties in a syntax similar to the original DSML. A major advantage of this approach is that the modeller specifies both requirements (in the form of properties) and design models in a familiar notation. The properties modelled in this domain-specific syntax are verified by mapping them to lower-level languages, such as Promela, and results are mapped back to the domain-specific level. To illustrate the approach, we create a DSML for modelling the human–computer interaction interface of a nuclear power plant.