Describing visual languages Lessons from abusing the Moses

Describing visual languages Lessons from abusing the Moses tool suite Jörn W. Janneck The Ptolemy Group University of California at Berkeley

overview attribute editing editor customization attributes derived attributes describing VLs attribute dependency management predicates introduction kinds of VLs lessons Jörn W. Janneck modular syntax description friendly syntax description 2 interaction advanced syntactic properties hierarchy textual languages The Ptolemy Group University of California at Berkeley

credits u Robert Esser, Adelaide University, Australia u Lothar Thiele, ETH Zurich u as well as – Martin Naedele, ABB Switzerland – Kim Mason, ETH Zurich – Manuel Hilty, ETH Zurich – Simon Künzli, ETH Zurich – Yan Ying, Adelaide University – and many others Jörn W. Janneck 3 The Ptolemy Group University of California at Berkeley

What's Moses? u modeling environment – originally for discrete-event systems – configurable visual editor – very stable simulation engine – configurable tool environment u open everything –. . . -source –. . . platform design –. . . community u developed at ETH Zurich – mainly academic users (Adelaide, Berkeley, Lund, some places in Germany) – a few interesting industrial uses (that we know of) Jörn W. Janneck 4 The Ptolemy Group University of California at Berkeley

design principle Reduce buy-in. u Try not to make users adopt things they do not care about. – They won't. u Allow them to choose, mix, and match. u Guidelines: – make it easy to use – make it easy to extend – make it easy to integrate other tools/code – make it easy to integrate the tool and its products u and above all: – make it easy to throw (parts of it) away » aggressive decoupling between the pieces of the tool suite Jörn W. Janneck 5 The Ptolemy Group University of California at Berkeley

What kind of visual language? Petri nets state machines dataflow process networks Jörn W. Janneck 6 The Ptolemy Group University of California at Berkeley

What's in a visual language? example: Petri nets There are two kinds of vertices. There are constraints on how they may be assembled. There are two kinds of edges. Vertices and edges have attributes. Jörn W. Janneck 7 The Ptolemy Group University of California at Berkeley

GTDL object types attribute type attribute name vertex type Place (expression Initial. Tokens) graphics (hidden string Shape = "Oval", hidden color Color = "black", hidden color Fill. Color = "yellow", hidden integer Extent. X = 24, hidden integer Extent. Y = 24). visual definition Jörn W. Janneck . . . which we usually don’t want to bother the user with 8 The Ptolemy Group University of California at Berkeley

GTDL object types edge type Arc (integer Weight) graphics (hidden string Head = "Closed. Triangle", hidden color Color = "black", hidden color Fill. Color = "black"). u configurable attribute editors u pluggable parsers – allows embedding of textual languages u library of predefined graphical stuff – shapes – line types – arrow heads – colors Jörn W. Janneck 9 The Ptolemy Group University of California at Berkeley

customizing the editor language-specific tool bars/menus object-specific attribute editors Jörn W. Janneck 10 The Ptolemy Group University of California at Berkeley

customizing the editor syntax specification editor configuration u many temptations – menus/toolbars – special interactions – animation/visual appearances – data formats – semantics u editor dependency is evil – increases buy-in fewer users – reduces reusability and portability – makes specifications more brittle » whenever the editor changes, language specifications might break u very difficult line to draw Jörn W. Janneck 11 The Ptolemy Group University of California at Berkeley

syntactic constraints u Not every attributed graph is a well-formed Petri net. u possible syntactic constraints: – non-empty presets of transitions – bipartiteness – Weight and Initial. Token attributes must be either absent or be positive or non-negative integers, respectively A picture is well-formed if it satisfies all syntactic constraints (syntax predicates) defined for its type. u difference to textual languages: Grammars and productions are not a very intuitive tool for describing those constraints! Jörn W. Janneck 12 The Ptolemy Group University of California at Berkeley

GTDL syntax predicates predicate expression (here quantified) error message predicate "Arcs from places must end at transitions. " forall e in Arc : src(e) in Place ==> dst(e) in Transition end vertex and edge types are sets Jörn W. Janneck 13 The Ptolemy Group University of California at Berkeley

GTDL syntax predicates predicate "Transitions must have a non-empty preset. " forall t in Transition : exists a in Arc : dst(a) = t end Jörn W. Janneck 14 The Ptolemy Group University of California at Berkeley

non-intrusive syntax checking u report the presence of syntax errors, but. . . – allow user to proceed (do not interfere with editing) – allow user to ignore the report » in fact, make it easy to ignore, this is the most common case! u give details on demand – no modal dialog – allow visual selection of location Jörn W. Janneck 15 The Ptolemy Group University of California at Berkeley

halftime attribute editing editor customization 1 attributes derived attributes describing VLs attribute dependency management predicates introduction kinds of VLs lessons Jörn W. Janneck modular syntax description friendly syntax description 16 interaction advanced syntactical properties 2 hierarchy 3 textual languages The Ptolemy Group University of California at Berkeley

derived attributes u 'ports' are just vertex decorations – they are attributes, like color, or size – the vertex shape recognizes these, and renders them accordingly u How should a user specify them? – explicitly? – as a function of some other attribute, such as Component. Class? Jörn W. Janneck 17 The Ptolemy Group University of California at Berkeley

GTDL derived attributes vertex type Process (string Name, string Component. Class, expression Constructor, derived Input. Connectors = inputs(this(“Component. Class")), derived Output. Connectors = outputs(this(“Component. Class")) ). . . u derived attributes are computed from other attributes – these are derived or explicitly specified – they could be anywhere in the graph, in subgraphs, . . . – the expression can navigate the graph using some free variables – this, G, V, E, the edge/vertex types Jörn W. Janneck 18 The Ptolemy Group University of California at Berkeley

derived attributes implementation issues u generality – attributed graph is a very general data structure » may contain subgraphs/supergraphs, dependencies can cross graph boundaries u dependency tracking u efficiency – do not re-compute attributes unnecessarily u correctness – detect cyclic dependencies Jörn W. Janneck 19 The Ptolemy Group University of California at Berkeley

derived attributes implementation issues u interaction – do not block user interaction during recomputation – minimize surprise when incrementally updating the graph – proper synchronization with user modifications u data storage – keep explicitly added and derived data separate -- user data is much more valuable! u NB: Syntax checking is a special case of derived attribute evaluation! u Moses currently has only an incomplete implementation of this. Jörn W. Janneck 20 The Ptolemy Group University of California at Berkeley

advanced syntactic constructions u Real-world visual notations are not quite as simple as the simple Petri nets. They often require more elaborate techniques because. . . –. . . they contain other visual notations. –. . . they contain textual notations. Jörn W. Janneck 21 The Ptolemy Group University of California at Berkeley

embedded visual notations modifying vertex/edge types vertex type Place (integer Initial. Tokens, graph("Petri. Net") Refinement). . . vertex type Transition (string Name). . . edge type Arc (string Name). . . Jörn W. Janneck 22 The Ptolemy Group University of California at Berkeley

embedded visual notations graph attributes (derived) these are attributes of the embedded graph itself Jörn W. Janneck attribute { derived Input. Transition. Names = {t("Name") : for t in Transition, t("Name") <> null, preset(t) = {}}, derived Output. Transition. Names = {t("Name") : for t in Transition, t("Name") <> null, postset(t) = {}} } 23 The Ptolemy Group University of California at Berkeley

embedded visual notations syntax predicate this predicate is part of the description of the embedding graph (type) predicate "Input transitions of a place refinement must match the preset of the place. “ forall p in {p : for p in Place, p("Refinement") <> null} : let s 1 = p("Refinement")("Input. Transition. Names"), s 2 = {t("Name") : for t in preset(p)} : s 1 = s 2 end Jörn W. Janneck 24 The Ptolemy Group University of California at Berkeley

embedded visual notations view of the editor Jörn W. Janneck 25 The Ptolemy Group University of California at Berkeley

embedded textual notations parsed textual attributes vertex type Place ( parsed string(“elan. parser. Elan. Parser”) Initial. Tokens). . . vertex type Transition ( parsed string(“elan. parser. Elan. Parser”) Guard). . . edge type Arc (integer Weight, string Var. Name, parsed string(“elan. parser. Elan. Parser”) Values). . . Jörn W. Janneck 26 The Ptolemy Group University of California at Berkeley

embedded textual notations function declarations declare { arc. Vars = lambda (s) { a("Var. Name") : for a in s, a("Var. Name") <> null } end, incoming. Arcs = lambda (v) {a : for a in E, dst(a) = v} end, free. Vars = lambda (expr). . . end } Jörn W. Janneck 27 The Ptolemy Group University of California at Berkeley

embedded textual notations syntax predicates predicate "Variable names on PT-arcs must be unique. " forall a in Arc: exists b in Arc: (dst(a) = dst(b)) && (a("Var. Name") = b("Var. Name")) end predicate "Free variables in transition guard must be incoming arc labels. " forall t in Transition : t("Guard") <> null ==> free. Vars(t("Guard")) <= arc. Vars(incoming. Arcs(t)) end Jörn W. Janneck 28 The Ptolemy Group University of California at Berkeley

almost there attribute editing editor customization attributes derived attributes describing VLs attribute dependency management predicates introduction kinds of VLs lessons Jörn W. Janneck modular syntax description friendly syntax description 29 interaction advanced syntactical properties hierarchy textual languages The Ptolemy Group University of California at Berkeley

How to make VL syntax modular? Some speculation. module Bipartite(V 1, V 2, E) { predicate V 1 * V 2 = {} end predicate forall e in E: (src(e) in V 1 ==> dst(e) in V 2) and (src(e) in V 2 ==> dst(e) in V 1) end } u syntax modules – collections of predicates, attribute definitions, functions – parameterizable – namespace u some issues – error message – error localization Jörn W. Janneck 30 The Ptolemy Group University of California at Berkeley

How to make VL syntax palatable? Visual. GTDL -- an experimental visual syntax description language definition of a simple Petri net language Jörn W. Janneck definition of the syntax of Visual. GTDL 31 The Ptolemy Group University of California at Berkeley

How to make VL syntax palatable? Visual. GTDL -- an experimental visual syntax description language u dataflow metaphor – but really represents sets, maps, predicates – good prospects for composition/abstraction u represents predicate structures visually – the phrase above expresses bipartiteness in Petri nets – syntax 'design patterns'? Jörn W. Janneck 32 The Ptolemy Group University of California at Berkeley

Finally - the lessons. u many different ways of writing visual syntax – productions are cumbersome – difference to textual languages – possible reasons » complexity of the 'alphabet'? » relation to interaction? » age of discipline? – predicates are very straightforward u editing environments should focus on flexible interaction – passive vs active editors – individual preferences – most of the time, the visual program is incorrect u visual syntax definition editor configuration Jörn W. Janneck 33 The Ptolemy Group University of California at Berkeley

Finally - the lessons. u visual syntax only is not very interesting – nobody connects a place to a place, but it's easy to use an undefined variable in a textual label – embedding textual languages and other visual languages – allow static checks on their interaction is essential u use simple, flexible data structure – it will change anyway – people will want to process it – it needs to be made persistent u some open issues: – modularity for visual language syntax descriptions – a canonical way of describing VL syntax Jörn W. Janneck 34 The Ptolemy Group University of California at Berkeley

Thank you. Jörn W. Janneck 35 The Ptolemy Group University of California at Berkeley