towards the generation of a text-based ide from a...

60
Towards the Generation of a Text-Based IDE from a Language Metamodel Presentation for MODSE by Anneke Kleppe

Upload: phamliem

Post on 10-May-2018

216 views

Category:

Documents


2 download

TRANSCRIPT

Towards the Generation of a Text-Based IDE from a Language Metamodel

Presentation for MODSEby

Anneke Kleppe

11-5-2007 1

Contents

Context of this research: Grasland projectApproaches to generation of toolsDifferences metamodel – grammarAlgorithms usedDemo

11-5-2007 2

Context

Grasland: Graphs for Software Language DefinitionsDesign a meta language to define software languages including their semantics.

11-5-2007 3

Proposition 1

Software applications are built using multiple languages.

At same level of abstractionAt different level of abstraction

Business process notation, like BPMN HTML

Java .NETUML Software requirements notation, like SRS

Petri netsHibernate

C#SQL JSP Software test notation, like TTCN

11-5-2007 4

Proposition 2

No real difference between programming and modeling languages. [Kleppe2005]

Modeling Programmingimprecise precisenot executable executableoverview detailed viewvisual/graphical textualinformal semantics execution semanticsanalysis by-product end-product

11-5-2007 5

Proposition 3

Each language can have multiple syntaxes, textual, graphical, or hybrid,

i.e. UML diagram, UML HUTN, UML XMI.

Syntax is way to structure linguistic utterance.

Natural Language Examples

11-5-2007 6

First Conclusion

Need for common representation in order to bind syntaxes to one language.

11-5-2007 7

Proposition 4

When defining languages both syntax and semantics are relevant.

Static semantics should be considered syntax. [HarelRumpe2004]

11-5-2007 8

Proposition 5

Language concepts are the pivot between syntax and semantics.

Usually these are called abstract syntax.

11-5-2007 9

The Meaning Triangle

Real world objectLinguistic symbol

“The Larch”

ConceptLarch tree

Ogden and Richards (1923)

11-5-2007 10

Second Conclusion

Language design should focus on Abstract Syntax Specification.

Description of language concepts

11-5-2007 11

Proposition 6

BNF grammar is set of rules that specifies how linguistic utterance can be created,

Or decided.

BNF grammar determines tree structure.Node is application of rule.Form of tree is regarded as structure of utterance

BNF grammar steers parsing.

11-5-2007 12

Proposition 7

Model is a special kind of graph.Attributed graphNode and edge inheritanceTwo-way associations with multiplicitiesDistinction between reference and containment edges

Instance of model M is a special graph with a typing morphism to M.

Containment edges in M specify tree in instance(To be published.)

11-5-2007 13

Proposition 8

Graph grammars create graph structured linguistic utterances.

Rule applications also builds graph

Grammar steers parsing.

A

B

A

B

C

A

AC

11-5-2007 14

Proposition 9

Semantics of language can be specified by a graph grammar.

[KKR2006]Start graph: abstract syntax graph

Semantics of model/program can be represented by state transition system.

States: extension of abstract syntax graph with values and processesTransitions: application of graph grammar rules

11-5-2007 15

Third Conclusion

BNF Grammars < Models < Graph Grammars.Models can be used as syntax-semantics pivot.Models can be used as syntax-syntax pivotUse a model to specify language concepts.

Usually called metamodel

11-5-2007 16

Defining Textual Syntax

11-5-2007 17

Traditional Compiler Approach

Textual syntax onlyNo (separate) Abstract Syntax SpecificationStatic semantic analysis handmade

symbol table

11-5-2007 18

Visual Language Design

Visual (graphical) syntaxSome support for hybrid syntax

Various grammar formalismsMost attributed BNF

Abstract syntax as attributes to concrete syntax

11-5-2007 19

Graph Grammar Approach

Visual (graphical) syntaxNo support for hybrid syntax

Formal, but not much used in practiceConcrete syntax as attributes to abstract syntax

11-5-2007 20

The Grasland Approach

Complete separation of abstract and concrete syntax => multiple concrete syntaxes possibleAll IDE parts generated from ASMOptional extra input to generation to ‘tune’output

11-5-2007 21

Diffs Metamodel - Grammar

Containment – reference distinctionModel-level: asm2pm transformationInstance-level: static semantic analysis

Order and keywords not in metamodelModel-level: pm2bnf transformation Instance-level: parsing

11-5-2007 22

Asm2pm

Is transformation of metamodel, thus defined on OMG level 3 (MOF)Splitting the binding

11-5-2007 23

Asm2pm algorithmASM class becomes PM class.

PM names use prefix and postfix strings. E.g. Variable becomes TextVariableSyntax.Abstract ASM class: both abstract and concrete.

Composite associations retained.Non-composite association: new class that represents a reference introduced.

The role name and multiplicities are copied.Attribute with non-primitive type: composite association.

The name and multiplicities are copied. Enumerations and data types are retained.

11-5-2007 24

More diffs ASM - PM

To create a larger difference between the ASM and PM, the language designer can:

Hide ASM classesHide ASM associations or attributes: OCL derivation rule must be given

11-5-2007 25

Example

In properties file:#---DERIVED ELEMENTSExpression.resultType=DERIVEDNullLitExp.value=DERIVED

#---HIDDEN ELEMENTSNullType=HIDDENPrimitiveType=HIDDEN

In constraints:context CreateExp::resultTypederive : type …

11-5-2007 26

ASM

11-5-2007 27

PM

11-5-2007 28

Asm2pm Overview

Completely AutomatedContainment - Reference

Handling totally determined by ASM.

Some tuning options for language designer

11-5-2007 29

Pm2bnf

Is transformation of metamodel, thus defined on OMG level 3 (MOF)Adding order and keywords

11-5-2007 30

Pm2bnf algorithmPM class becomes non-terminal.If subclasses then super BNF rule becomes choice between subclass rules.

All attributes and navigations are handled in the subclass rules.

Composite association A to B:B in RHS of ruleMultiplicities are taken into account

Attribute of Integer, String, or Real type is transformed into predefined non-terminal.Attribute of Boolean type is transformed into an optional keyword.

11-5-2007 31

Keywords

Possibilities:Before class, After class,Before attribute or association end,After attribute or association end,Separator to attribute or association end with multiplicity many.

Automatically all keywords are generated.Tuning possible

11-5-2007 32

Example

Program ::= PROGRAM_BEGIN

PROGRAM_NAME_BEGIN stringPROGRAM_NAME_END [ PROGRAM_TYPES_BEGIN TypeDecl( PROGRAM_TYPES_SEPARATOR TypeDecl )*PROGRAM_TYPES_END ]

PROGRAM_END

11-5-2007 33

Ordering

Automatically random ordering is generatedTuning possible

11-5-2007 34

Identifiers vs. Strings

Some attributes of String type need to be regarded as Identifiers.

Automatically none are recognizedTuning possible

11-5-2007 35

Tuning

Currently implemented in properties file, i.e. simple list of A = B statements

Investigating more practical ways

11-5-2007 36

ExampleBLOCKSTAT_BEGIN=CURLY_OPENBLOCKSTAT_END=CURLY_CLOSECREATEEXP_BEGIN=newCREATEEXP_END=()NULLLITEXP_BEGIN=nullOBJECTTYPE_ATTRIBUTES_END=SEMICOLONOBJECTTYPE_ATTRIBUTES_SEPARATOR=SEMICOLONOBJECTTYPE_BEGIN=classOBJECTTYPE_END=end_classOBJECTTYPE_SUPERTYPE_BEGIN=extendsOBJECTTYPE_ORDER_1=nameOBJECTTYPE_ORDER_2=superTypeOBJECTTYPE_ORDER_3=attributesOBJECTTYPE_ORDER_4=operations

11-5-2007 37

Example ContinuedOPERCALLEXP_ACTUALPARS_BEGIN=BRACKET_OPEN

<MANDATORY>OPERCALLEXP_ACTUALPARS_END=BRACKET_CLOSE

<MANDATORY>OPERCALLEXP_ACTUALPARS_SEPARATOR=COMMA

#---IDENTIFIERS---TYPE_ID=namePROGRAM_ID=nameVARDECL_ID=nameOPERDECL_ID=name

11-5-2007 38

Multiplicities

Combined with mandatory keywords, the options [0..1], [0..*], [1..1], [1..*] determine 19 different BNF rules.All possibilities automatically generated.

No human errors

11-5-2007 39

Lists 11. [ BEGIN_KW elemCall ( SEPARATOR elemCall)* END_KW ]2. BEGIN_KW [ elemCall ( SEPARATOR elemCall)* END_KW ]3. [ BEGIN_KW elemCall ( SEPARATOR elemCall)* ] END_KW 4. BEGIN_KW [ elemCall ( SEPARATOR elemCall)* ] END_KW5. [ BEGIN_KW (elemCall)* END_KW ]6. (elemCall)*7. BEGIN_KW [ (elemCall)* END_KW ]8. BEGIN_KW (elemCall)*9. [ BEGIN_KW (elemCall)* ] END_KW10. (elemCall)* END_KW

11-5-2007 40

Lists 21. BEGIN_KW (elemCall)* END_KW2. [ BEGIN_KW ] elemCall ( SEPARATOR elemCall)* [ END_KW ]3. BEGIN_KW elemCall ( SEPARATOR elemCall)* [ END_KW ]4. [ BEGIN_KW ] elemCall ( SEPARATOR elemCall)* END_KW 5. BEGIN_KW elemCall ( SEPARATOR elemCall)* END_KW6. [ BEGIN_KW ] (elemCall)+ [ END_KW ]7. BEGIN_KW (elemCall)+ [ END_KW ]8. [ BEGIN_KW ] ( elemCall )+ END_KW9. BEGIN_KW ( elemCall )+ END_KW

11-5-2007 41

PM

11-5-2007 42

BNFCreateExp::= <CREATEEXP_BEGIN> type:ObjectTypeREF <CREATEEXP_END>

Expression ::= (LiteralExp | OperCallExp | VarCallExp | CreateExp)

ObjectTypeREF ::= ID:<IDENTIFIER>

ObjectType ::= <OBJECTTYPE_BEGIN> name:<IDENTIFIER>

[ <OBJECTTYPE_SUPERTYPE_BEGIN> superType:ObjectTypeREF]

[ attributes:VarDecl ( <SEMICOLON> attributes:VarDecl )* <SEMICOLON> ]

( operations:OperDecl )* <OBJECTTYPE_END>

OperCallExp ::= referredOper:OperDeclREF

<BRACKET_OPEN> [ actualPars:Expression

( <COMMA> actualPars:Expression )* ] <BRACKET_CLOSE>

[ <OPERCALLEXP_SOURCE_BEGIN> source:Expression ]

11-5-2007 43

Pm2bnf Overview

Fully automatedPlenty possibilities for tuning

KeywordsOrderingIdentifiers

11-5-2007 44

Parsing

Is transformation of instance, thus resides on OMG level 2Building tree from sequence

11-5-2007 45

Parsing 2

Output of generated parser is instance of PMImplemented using existing technology: JavaCC

Pm2bnf generates either BNF or JavaCCinput

11-5-2007 46

Static Semantic Analysis

Is transformation of instance, thus resides on OMG level 2(Re)building ASM instance

11-5-2007 47

General SSA Tasks

BindingMaking graph from a treeDynamic binding is NOT part of SSA

CheckingDone after binding

11-5-2007 48

Binding in Grasland toolkit

Remove all instances of REF-classes Replace incoming links to REF-classes with links to instance of original class (target class)To implement lookup algorithm namespaces are needed

Another tuning optionSimple or complex namespaces

11-5-2007 49

Example#----NAMESPACESTYPE=NAMESPACEPROGRAM=NAMESPACEOPERDECL=NAMESPACE

#----COMPLEX NAMESPACESNAMESPACE.OperCallExp=if not source.oclIsUndefined()

then source.resultType else DEFAULT endifNAMESPACE.VarCallExp=if not source.oclIsUndefined()

then source.resultType else DEFAULT endif

11-5-2007 50

Simple or Complex Binding

Simple binding based on Identifiers and namespaces only

Using Identifiers from pm2bnf.Standard algorithm using nested namespaces

Complex binding based on Ids, Ns, and constraints in ASM

Element is bound only if constraint holds for bound situationImplemented by backtracking

11-5-2007 51

Example

In properties file:#---COMPLEX REFERENCESOperCallExp.referredOper=paramCheck

In constraints:context OperCallExpinv paramCheck: referredOper.params.type =

actualPars.resultType

11-5-2007 52

Checking

All invariants defined on ASM are checked

Tuning of error messages possible

Example type check:context VarDeclinv typeCheck: not initExp.oclIsUndefined() implies

self.type.conformsTo(initExp.resultType)

11-5-2007 53

ExampleIn properties file: #---CHECKER ERROR MESSAGESattributeNamesMustBeUnique=Not all attribute names are uniqueoperationsMustBeUnique=Not all operations have a unique

signature

In constraints:context ObjectTypeinv attributeNamesMustBeUnique: attributes->isUnique(name)context Typeinv operationsMustBeUnique: operations->forAll( o1, o2 | (o1 <>

o2 and o1.name = o2.name) implies o1.params.type <> o2.params.type )

11-5-2007 54

SSA Overview

SSA completely generatedNamespaces

Includes complex forms of bindingConstraint on binding

Includes many checksDefined by OCL invariants

11-5-2007 55

Summary

Complete separation of abstract and concrete syntax => multiple concrete syntaxes possibleAll IDE parts generated from ASMOptional extra input to generation to ‘tune’output

11-5-2007 56

Conclusion

It is possible to generate text-based IDE from a metamodel

Including parser, SSA Unparser, dedicated editor future work

Input from language designer is minimal, i.e. less is not possible

Manner in which extra input is given can be improved

11-5-2007 57

Open issues / future workDealing with expressions

Infix/prefix/postfix operatorsPriorities

Primitive typesHandling ambiguous BNF rules

Problem only when ‘tuned’Left recursion errorsChoice conflicts

Binding based on qualified idsLarger differences between ASM and PM

11-5-2007 58

Questions and References[Kleppe2005] Anneke Kleppe, Towards General Purpose, High Level, Software Languages. A. Hartman and D. Kreische (Eds.): ECMDA-FA 2005, LNCS 3748, pp. 220 – 238, 2005.[HarelRumpe2004] David Harel and Bernhard Rumpe, Meaningful Modeling: What's the Semantics of "Semantics"?, IEEE Computer, Vol. 37, Nr. 10, pp. 64-72, 2004[Kleppe2007] Anneke Kleppe, Towards the Generation of a Text-Based IDE from a Language Metamodel, to appear in ECMDA-FA 2007[KKR2006] Kastenberg, H., Kleppe, A., and Rensink, A. Defining object-oriented execution semantics usinggraph transformations. In Gorrieri, R. and Wehrheim, H., editors, FMOODS 2006, volume 4037 of LNCS, pages 186–201, Berlin Heidelberg. [email protected]

11-5-2007 59

Demo …