Formal interpreters for diagram notations

Abstract

The article proposes an approach for defining extensible and flexible formal interpreters for diagram notations with significant dynamic semantics. More precisely, it addresses semi-formal diagram notations that have precisely-defined syntax, but informally defined (dynamic) semantics. These notations are often flexible to fit the different needs and expectations of users. Flexibility comes from the incompleteness or informality of the original definition and results in different interpretations.The approach defines interpreters by means of a mapping onto a semantic domain. Two sets of rules define the correspondences between the elements of the diagram notation and those of the semantic domain, and between events and states of the semantic domain and visual annotations on the elements of the diagram notation. Flexibility also leads to notation families, that is, sets of notations that share core concepts, but present slightly different interpretations. Existing approaches usually interpret these notations in isolation; the approach presented in this article allows the interpretation of a family as a whole. The feasibility of the approach is demonstrated through a prototype generator that allows users to implement special-purpose interpreters by defining relatively small sets of rules.

Supporting user-oriented analysis for multi-view domain-specific visual languages

“…The approach in [10] supports animation, but no further analysis techniques are provided. The work in [2] couples the creation graph grammar rules of the source and target notations. Then, the simulation steps in the semantic domain are translated back to the original notation using a textual language.…”

Prescriptive Semantics for Big-Step Modelling Languages

“…I call such a tool suite a tool-support generator framework (TGF), which takes the definition of a language, including its semantics, as input, and generates tool support, such as model checking and simulation capability for that language, as output [81,25,28,75,65,6,38,87]. TGFs differ in the semantic input formats (SIF) they use, and the procedure by which they obtain tool support for a language.…”

“…Implicit events may or may not have the same semantics as the event lifeline semantics of named events. 6 } is a valid big step, which both decreases and increases the amount of gas to the engine. The latter big step is globally inconsistent, because increase gas is sensed as absent by t 5 and is generated by t 6 .…”

“…6 } is a valid big step, which both decreases and increases the amount of gas to the engine. The latter big step is globally inconsistent, because increase gas is sensed as absent by t 5 and is generated by t 6 . If the variation of global consistency semantics in [66] is chosen, then {t 5 } is a valid big step; t 6 cannot be taken during the big step since it generates increase gas.…”

“…Table 3.6 shows the three possible memory protocols: (i) in the GC Big Step option, a read of a variable returns its value from the beginning of the big step; (ii) in the GC Small Step option, a read of a variable returns its value from the beginning of the small step; and (iii) in the GC Combo Step option, a read of a variable returns its value from the beginning of the current combo step. 6 As such, in the GC Big Step, the GC Small Step, and the GC Combo…”