Definition of Modeling vs. Programming Languages Maged Elaasar Jet Propulsion Laboratory, California Institute of Technology, Pasadena, CA 91109, USA [email protected] Abstract. Modeling languages (like UML and SysML) are those used in model- based specification of software-intensive systems. Like programming languages, they are defined using their syntax and semantics. However, both kinds of lan- guages are defined by different communities, and in response to different require- ments, which makes their methodologies and tools different. In this paper, we highlight the main differences between the definition methodologies of modeling and programming languages. We also discuss the impact of these differences on language tool support. We illustrate our ideas using examples from known pro- gramming and modeling languages. We also present a case study, where we an- alyze the definition of a new modeling language called the Ontology Modeling Language (OML). We highlight the requirements that have driven OML defini- tion and explain how they are different from those driving typical programming languages. Finally, we discuss how these differences are being abstracted away using new language definition tools. Keywords: Modeling, Programming, Syntax, Semantics, API, Methodology. 1 Introduction Model-driven engineering (MBE) is a methodology that focuses on creating and ex- ploiting models in the engineering of software-intensive systems. A model, expressed in a modeling language, is typically used to capture, communicate, and analyze the design of a software system. In a variant of the methodology, called model-driven de- velopment (MDD), the model is then transformed using a code generator into code in some programming language. Both modeling and programming languages are computer languages that are defined in terms of their syntax and semantics. The syntax specifies the abstractions that can be used to describe a system, whereas the semantics specifies the meanings assigned to these abstractions. Moreover, the syntax can be specified in two levels: abstract and concrete. The abstract syntax specifies the abstractions or building blocks of expres- sions in a language (e.g., classes, fields, methods in the Java language) independently of their representations. The concrete syntax specifies the representations (using textual or graphical notation) of those abstractions. Both syntaxes are often mappable to each other, although the typical direction and completeness of these mappings may vary be- tween modeling and programming languages. 2 The syntax of a programming language like Java, Scala or C++ is typically specified using a context-free grammar expressed in a notation like Backus-Naur Form (BNF) [1]. A BNF grammar consists of a set of terminal symbols, non-terminal symbols, and production rules (in the form <non-terminal> ::= <expression>) that transform each non-terminal into a sequence of terminals and/or non-terminals. This specifies the con- crete textual syntax of a programming language. Moreover, the abstract syntax is also (automatically) derivable from such grammar. It is represented as an abstract syntax tree (AST) that is made up of non-terminal nodes. However, such AST is context-free. Performing context analysis (gathering and checking semantics) on the AST is typically encoded manually in some imperative programming language. On the other hand, the abstract syntax of a modeling language, like UML [2], SysML [3] or BPMN [4], is typically specified using a meta (higher-level) modeling language like Meta Object Facility (MOF) [5]. A MOF-based metamodel specifies the abstrac- tions of a language as meta classes, that have properties, operations, relationships (e.g., generalizations, compositions, cross references) to other meta classes, and well- formedness rules, expressed in a rule language like the Object Constraint Language (OCL) [13]. Thus, unlike a BNF grammar, a MOF metamodel captures the semantic context of a modeling language (at least partially). Moreover, the concrete syntax of a modeling language is typically defined independently of the abstract syntax. There can be several concrete syntaxes for a language and each of them can be textual and/or graphical. While there are some standards that can be used to describe those concrete syntaxes, and their relationship to the abstract syntax, they are typically defined less formally using English prose. On the other hand, there exist some de facto frameworks that are widely used to specify those concrete syntaxes. (More on this in section 2.2.) Furthermore, modeling languages differ from programming languages in terms of their tooling concerns and approaches. For example, modeling languages tend to have standard APIs, hence many general-purpose tools (e.g., query engines, transformation engines, visualizers) can be developed generically for them. Also, models are often stored in persistent storage in terms of their abstract syntax, as opposed (or in addition) to their concrete syntax. This persistence is often standardized (in XML or JSON). Also, models can grow in size dramatically and hence sometimes get persisted in databases (as opposed to files) to enhance their scalability. Also, in a collaborative editing envi- ronment, models often need to be compared and merged in terms of their AST as op- posed to the persistent format. Models also often need to be visualized using a variety of notations and viewpoints. In this paper, we show how the methodology of defining modeling languages often differ from that of programming languages, in terms of abstract syntax, concrete syn- taxes and semantics. We also discuss the implications of these differences on language tooling concerns and approaches. We also report on a case study where a new modeling language, called the Ontology Modeling Language (OML) [6], has been defined. We highlight the requirements of OML, discuss how some of them may be different than typical ones for programming languages, and show how they have been addressed in the modeling language methodology. In addition, we reflect on the state of the practice in language definition today and highlight some technologies that have the potential to bring the two approaches closer together. 3 The rest of the paper is organized as follows. Section 2 describes the differences in the methodologies for defining programming vs. modeling languages. A discussion of the impact of these differences on language tooling is given in section 3. Section 4 presents a case study where the OML modeling language has been defined. Some re- flections on the state of the practice are offered in section 5. Finally, section 6 concludes the paper and outlines future works. 2 Definition of Modeling vs. Programming Languages In this section, we describe the different methodologies of defining programming and modeling languages. We structure the description along three dimensions: abstract syn- tax, concrete syntax, and semantics. 2.1 Programming Language Definition Concrete Syntax. The concrete syntax of a programming language is typically textual and specified with a context-free grammar that is expressed using a common notation like Backus-Naur Form (BNF) or Extended BNF (EBNF) [7] (which helps deal with some limitations of BNF like the definition of repeatable elements). Such notation al- lows specifying the textual syntax in two levels: a lexical level and a grammar level. The lexical level is specified with regular expressions that determine how characters form tokens (terminals). The grammar level is specified with production rules that de- termine how tokens (terminals) form phrases (non-terminals). For example, the follow- ing BNF grammar snippet specifies the syntax of simple algebraic expressions: <expr> ::= <term> "+" <expr> | <term> <term> ::= <factor> "*" <term> | <factor> <factor> ::= "(" <expr> ")" | <constant> <constant> ::= number With such grammar, the expression ‘(1 + 2) * (3 + 5)’ can be represented as a valid expression in the grammar. First, a lexer turns the sequence of characters into terminal tokens (e.g., ‘(‘, ‘1’, ‘+’, ‘2’, etc.). Then, a parser groups the terminals into non-termi- nals that are added as nodes in an abstract syntax tree (AST) using the BNF production rules. For example, the AST of the above expression can be represented in memory as [term, [factor, [expr, constant, constant]], [factor, [expr, constant, constant]], where each node is represented as [parent, child1, child2, …]. When such AST is printed, it can show as [‘*’, [‘(‘, [‘+’, ‘1’, ‘2’], ‘)’], [‘(‘, [‘+’, ‘3’, ‘5’], ‘)’]]. Both the lexer and the parser for a programming language can usually be auto-generated from the BNF gram- mar of a language, as supported by tools like Lex-Yacc [8] or Antlr [9]. Abstract Syntax. As mentioned before, BNF is a context-free grammar, which means the AST produced based on it is also context free. This means that the AST just shows the composition of the non-terminals, without interpreting what they semantically mean 4 nor how they are related semantically to each other. This is left to an interpreter that processes the AST and either adds to it semantic context, or produces another tree with semantic context. To clarify what is meant by this, consider the following example pro- gram file (example.java) expressed in the Java language: package a; import a.b.C; public class D extends C { } This file could be parsed using a (pseudo) Java BNF grammar as [‘example.java’, [package, ‘a’], [import, ‘a.b.C’], [class, ‘D’, [super, ‘C’]]]. With this AST, we can see the structure of the Java file, but what we cannot see yet is how the nodes of that struc- ture relate to each other. For example, the fact that class D belongs to package ‘a’, and that class C belongs to package ‘a.b’ is not automatically inferred by the parser. Rather, this information is added by the Java compiler that processes the AST to add the type information and creates the cross references. Only then, the AST of a program becomes ready to be checked for well-formedness. A compiler is usually coded manually as a visitor pattern over the AST. Semantics. The semantics of a programming language refers to the formal meanings of the abstractions of a language.