language workbench competition 2011 the oomega language workbench

www.xenium.deThe OOMEGA language workbench - www.oomega.net1

Language Workbench Competition 2011The OOMEGA language workbench

2011/05/24

Christian Merenda2011/05/24

www.xenium.deThe OOMEGA language workbench - www.oomega.net2 2011/05/24

Agenda

▶ Introducing the OOMEGA language workbench▶ Exploration of the Language Workbench Competition 2011

▸ The Preamble▸ Phase 0 – Basics▸ Phase 1 – Advanced▸ Phase 2 – Non-Functional▸ Phase 3 - Freestyle


Introducing the OOMEGA language workbench


OOMEGA is based on the Eclipse IDE

2011/05/24

OOMEGA is based on the Eclipse IDE

ATL support for model-to-model transformations

Xpand support for model-to-text

transformations


Correlation of the EdgeAlgebra, M2L, OOMEGA and metaMODELS.org

2011/05/24

Theoretical foundation for graph-based queriesEdgeAlgebra

based on

Formal and high expressive metamodelling languageM2L

implements

Open source implementation with commercial database backends

powered by

Platform for collaborative metamodel engineering


Clear separation of abstract and concrete syntaxes

2011/05/24

M E T A M O D E L - M2L –

Abstract Syntax

Concrete SyntaxConcrete Syntax

structure of the model

bridge the gap between this structureand concrete textual representations


Text editors with folding, linking and syntax highlighting

2011/05/24


Incremental parsing and projection of models

2011/05/24

Modelp1.Person p = { name = „Merenda“ firstname = „Christian“}

Text

Changes to the model are projected to the text.

Incremental update of the model if the text is changed.

OOMEGA has implemented its own scannerless parser; we do not rely on ANTLR or some other parser generator.


Various techniques for defining constraints

▶ Primary local keysmust be unique within the set of all sister nodes in the composition tree.

▶ Context sensitive domainsfurther constrain the domain of a property with respective Edge Algebra statements – beyond the traditional type safety.

▶ Weak entity and attribute conceptsmust be referenced by exactly one composite object.

▶ Multiplicitiesdefine lower and upper limits for the number of referenced objects in the context of a property.

▶ Abstract conceptscan’t be instantiated – i.e. corresponding objects must not exist in the database.

▶ Additional constraintsmust hold for every instance of the respective concept. Again – the Edge Algebra is used to define those constraints.

2011/05/24


Agenda

▶ Introducing the OOMEGA language workbench▶ Exploration of the Language Workbench Competition 2011

▸ The Preamble▸ Phase 0 – Basics▸ Phase 1 – Advanced▸ Phase 2 – Non-Functional▸ Phase 3 - Freestyle


The Preamble


We‘ve designed five interelated DSLs to showcase language modularity and composition

2011/05/24

Primitive

Expression

Domain

InstanceEntity

Relationship


No 3GL code / ~350 lines of code

▶ The final solution does not contain a single line of 3GL code for designing the language, implementing constraints or setting up text editors

▶ You need to code ~350 lines of code with OOMEGA’s meta-modelling language M2L in order to realize the whole functionality of the LWC2011 case

▶ You do only specify abstract and concrete syntaxes of your DSLs. That‘s it.

2011/05/24


Phase 0 - Basics


Task 0.1 - Simple (structural) DSL without any fancy expression language or such▶ Challenge: Build a simple data definition language to define

entities with properties. Properties have a name and a type. It should be possible to use primitive types for properties, as well as other Entities.

2011/05/24

entity Person { string name string firstname date bithdate Car ownedCar}

entity Car { string make string model}


The language module „Primitive“

2011/05/24



▶ [Primitive!!] refines AttributeObject ::> ;

▶ P_String!! refines Primitive ::= &javaMapping[0..1](Singleton) : C:String := {{ String }}, &xmlMapping[0..1](Singleton) : C:String := {{ String }} ;

▶ P_Date!! refines Primitive ::= &javaMapping[0..1](Singleton) : C:String := {{ "java.util.Date" }}, &xmlMapping[0..1](Singleton) : C:String := {{ Date }} ;

2011/05/24



▶ textual concrete syntax LWC { <default> P_String : "string" ; <default> P_Date : "date" ;}

▶ textual concrete syntax SQL { P_String : "CHAR" ; P_Date : "DATE" ;}

2011/05/24


The language module „Domain“

▶ DomainModel! refines FolderEntry ::= packages[0..*](Set) <-> belongsTo : C:Package, &entities[0..*](Set) : C:Entity := (P:packages.P:entities) ;

▶ Entity! refines Named ::> &belongsTo[0..1](Singleton) <-> entities : C:Package, &usedBy[0..*](Set) <-> type : C:Association, properties[0..*](Set) <-> belongsTo : C:Prop, &attributes[0..*](Set) : C:Attribute := (P:properties projectOn C:org.metamodels.lwc2011.domain.Attribute), &associations[0..*](Set) : C:Association := (P:properties projectOn C:org.metamodels.lwc2011.domain.Association), &context[0..1](Singleton) : C:EntityObject := self ;

2011/05/24



▶ [Prop!] refines Named ::> &belongsTo[0..1](Singleton) <-> properties : C:Entity ;

▶ Attribute! refines Prop ::> type[1..1](Singleton) : C:Primitive ;

▶ Association! refines Prop ::> &type[1..1](Singleton) <-> usedBy : C:Entity projectOn ((P:belongsTo.P:belongsTo.P:entities) union (P:belongsTo.P:belongsTo.P:importedPackages.P:entities)), &includedContext[0..*](Set) : C:EntityObject := (P:belongsTo.P:belongsTo.P:importedPackages) ;

2011/05/24



▶ textual concrete syntax DIRECTORY { <helper> DomainModel : "domain" _ "model" _ <Named> ;}

▶ textual concrete syntax LWC { <default> DomainModel : "domain" _ "model" _ <Named> _ "{" (nl | P:packages) nl "}" ; <default> Entity : "entity" _ <Named> _ "{" (nl | P:properties) nl "}" ; <default> Attribute : (!P:type) _ <Named> ; <default> Association : "ref" _ (&P:type) _ <Named> ;}

2011/05/24


Task 0.2 - Code generation to GPL such as Java, C#, C++ or XML▶ Challenge: Generate Java Beans (or some equivalent data

structure in C#, Scala, etc.) with setters, getters and fields for the properties.

▶ Solution: Code can be generated with OOMEGA‘s generator or Eclipse Xpand. We demonstrated the usage of Xpand. Basically this can be done in three simple steps:▸ Code a Xpand template▸ Create a workflow▸ Execute the workflow within an Ant script

2011/05/24

Due to time restrictions the code generation task is not explained here. Please have a look at our online documentation of the LWC2011 case.


Task 0.3 - Simple constraint checks such as name-uniqueness▶ Challenge: For example, check the name uniqueness of the

properties in the entities.▶ Solution: The name uniqueness of the properties in the

entities is already built in.▸ [Prop!] refines Named ::>

&belongsTo[0..1](Singleton) <-> properties : C:Entity ;

▸ [Named] refines EntityObject ::> (PK)name[1..1](Singleton) : C:String, (K)alternativeName[0..*](Set) : C:String

▶ Primary local keys must be unique within the set of all sister nodes in the composition tree. This means in our example: an Entity mustn’t contain multiple properties with identical names.

2011/05/24


Task 0.4 - Show how to break down a (large) model into several parts, while still cross-referencing between the parts▶ Challenge: For example, put the Car and Person entities into

different files, while still having the Person -> Car reference work.

2011/05/24

ViewAspect

PersistenceAspect

If you’ve got a large model you want to be able to view

only parts of it.

A large model shouldn’t be stored in a single text file.

Models are – by default – partitioned into little pieces: you can always decide which object to view or edit. The persistence aspect is solved by appropriate

storage back-ends, e.g. an object-oriented database.


Phase 1 - Advanced


Task 1.1 - Show the integration of several languages▶ Challenge: Define a second language to define instances of

the entities, including assignment of values to the properties. This should ideally really be a second language that integrates with the first one, not just "more syntax" in the same grammar. We want to showcase language modularity and composition here.

2011/05/24

Person p = { name = "Voelter" firstname = "Markus" birthdate = 14.02.1927 ownedCar = c}

Car c = { make = "VW" model = "Touran"}


The language module „Instance“

▶ InstanceModel! refines FolderEntry ::= &basedOn[0..1](Singleton) : C:DomainModel, instances[0..*](Set) <-> belongsTo : C:Instance ;

▶ Instance! refines Named ::> &belongsTo[0..1](Singleton) <-> instances : C:InstanceModel, &entity[0..1](Singleton) : C:Entity projectOn (P:belongsTo.P:basedOn.P:entities), propertyValues[0..*](Set) <-> belongsTo : C:PropertyValue, &includedContext[0..*](Set) : C:EntityObject := (P:belongsTo.P:basedOn) ;

2011/05/24



▶ PropertyValue! refines EntityObject ::> &belongsTo[0..1](Singleton) <-> propertyValues : C:Instance, (PK)&property[0..1](Singleton) : C:Prop projectOn (P:belongsTo.P:entity.P:properties), val[1..1](Singleton) : C:Value, &includedContext[0..1](Singleton) : C:EntityObject := (P:belongsTo.P:entity)

▶ [Value!!] refines AttributeObject ::> ;▶ V_Boolean!! refines Value ::>

booleanValue[1..1](Singleton) : C:Boolean ;▶ V_Ref!! refines Value ::>

&refValue[0..1](Singleton) : C:Instance ;

2011/05/24



▶ textual concrete syntax DIRECTORY { <helper> InstanceModel : "instance" _ "model" _ <Named> ;}

▶ textual concrete syntax LWC { <default> InstanceModel : "instance" _ "model" _ <Named> _ ("based" _ "on" _ || &P:basedOn / "," || _) "{" (nl | P:instances) nl "}" ; <default> Instance : (&P:entity) _ <Named> _ "=" _ "{" (nl | P:propertyValues) nl "}" ; <default> PropertyValue : (&P:property) _ "=" _ (P:val) ; <default> V_Boolean : (P:booleanValue) ; <default> V_Ref : (&P:refValue) ;}

2011/05/24


Instance model

2011/05/24


Task 1.2 - Demonstrate how to implement runtime type systems▶ Challenge: The initialization values in the instance-DSL must

be of the same type as the types of the properties.

2011/05/24

The implementation of the runtime type system can be achieved with only one additional constraint for the concept PropertyValue in the language module “Instance”.


Additional constraint „typeSafety“

▶ PropertyValue! refines EntityObject ::> (PK)&property[0..1](Singleton) : C:Prop projectOn (P:belongsTo.P:entity.P:properties), val[1..1](Singleton) : C:Value, where typeSafety["Type of the value must match the property's type"]: (P:property consistsOf C:Association => (P:val consistsOf C:V_Ref & (P:property.P:type) = (P:val.P:refValue.P:entity))) & (P:property consistsOf C:Attribute => (((P:property.P:type) consistsOf C:P_Boolean => P:val consistsOf C:V_Boolean) & ((P:property.P:type) consistsOf C:P_Date => P:val consistsOf C:V_Date) & ((P:property.P:type) consistsOf C:P_Natural => P:val consistsOf C:V_Natural) & ((P:property.P:type) consistsOf C:P_String => P:val consistsOf C:V_String))) ;

2011/05/24


Task 1.3 - Show how to do a model-to-model transformation▶ Challenge: Define an ER-meta model (Database, Table,

Column) and transform the entity model into an instance of this ER meta model.

▶ Solution: Model-to-model transformations can be done with ATLAS Transformation Language (ATL). Basically this can be done in two simple steps:▸ Code an ATL template▸ Execute the ATL transformation within an Ant script

2011/05/24

Due to time restrictions the model-to-model transformation with ATL is not explained here. Please have a look at our online documentation.


The language module „EntityRelationship“

▶ Database! refines FolderEntry ::= tables[0..*](Set) <-> belongsTo : C:Table ;

▶ Table! refines Named ::> &belongsTo[0..1](Singleton) <-> tables : C:Database, columns[1..*](Set) <-> belongsTo : C:Column, foreignKeys[0..*](Set) <-> belongsTo : C:ForeignKey ;

▶ Column! refines Named ::> &belongsTo[0..1](Singleton) <-> columns : C:Table, type[1..1](Singleton) : C:Primitive, length[0..1](Singleton) : C:Natural, primaryKey[1..1](Singleton) : C:Boolean

2011/05/24



▶ ForeignKey! refines EntityObject ::> &belongsTo[0..1](Singleton) <-> foreignKeys : C:Table, &fkColumn[1..1](Singleton) : C:Column projectOn (P:belongsTo.P:columns), &referencedTable[1..1](Singleton) : C:Table projectOn (P:belongsTo.P:belongsTo.P:tables), &referencedColumn[1..1](Singleton) : C:Column projectOn (P:referencedTable.P:columns) ;

2011/05/24



▶ textual concrete syntax DIRECTORY { <helper> Database : "database" _ <Named> ;}

▶ textual concrete syntax LWC { <default> Database : "database" _ <Named> _ "{" (nl | P:tables) nl "}" ; <default> Table : "table" _ <Named> _ "{" (nl | P:columns / ",") ("," || nl | P:foreignKeys / ",") nl "}" ; <default> Column : ((bool)P:primaryKey ? "pk" _ : "") (!P:type) ("(" | P:length | ")") _ <Named> ; <default> ForeignKey : "fk" _ (&P:fkColumn) _ "references" _ (&P:referencedTable) ("(" | &P:referencedColumn | ")") ;}

2011/05/24



▶ textual concrete syntax SQL { <readonly> Database : "CREATE" _ "DATABASE" _ <Named> (nl | P:tables) ; <readonly> Table : "CREATE" _ "TABLE" _ <Named> nl "(" (nl | P:columns / ",") ("," || nl | P:foreignKeys / ",") nl ")" ; <readonly> Column : <Named> _ (P:type) ("(" | P:length | ")") ((bool)P:primaryKey ? _ "PRIMARY" _ "KEY" : "") ; <readonly> ForeignKey : "FOREIGN" _ "KEY" ("(" | &P:fkColumn | ")") _ "REFERENCES" _ (&P:referencedTable) ("(" | P:referencedColumn.P:name | ")") ;}

2011/05/24


E/R model: „LWC“ syntax tab

2011/05/24


E/R model: „SQL“ syntax tab

2011/05/24


Task 1.4 - Some kind of visibility/namespaces/scoping for references▶ Challenge: Integrate namespaces/packages into the entity

DSL

2011/05/24

package p1 { import p2 entity Person { string name string firstname date birthdate Car ownedCar }}package p2 { entity Car { string make string model }}


Task 1.4 - Some kind of visibility/namespaces/scoping for references▶ …and make sure in the instance DSL you can only assign

values to the properties of the respective entity, i.e. make sure that writing

is illegal.

2011/05/24

Car c = { birthdate = …}


Namespaces – Introducing the concept „Package“▶ DomainModel! refines FolderEntry ::=

packages[0..*](Set) <-> belongsTo : C:Package, ...

▶ Package! refines Named ::> &belongsTo[0..1](Singleton) <-> packages : C:DomainModel, entities[0..*](Set) <-> belongsTo : C:Entity, &importedPackages[0..*](Set) : C:Package, &path[0..1](Singleton) : C:String := Java: "return getName().replace('.', '/');" ;

▶ textual concrete syntax LWC { <default> Package : "package" _ <Named> _ "{" (nl "import" _ || &P:importedPackages / "," _) (nl | P:entities) nl "}" ;}

2011/05/24


Visibility and Scoping

▶ VisibilityAn entity can reference another entity only if the other entity is either part of the same package or part of an imported package.

▶ ScopingA package import leads to a scope expansion: if an entity of an imported package is referenced, then the package prefix can be omitted in the reference.

2011/05/24

The implementation of the features visibility and scoping takes only two lines of code.


Visibility and Scoping

▶ Association! refines Prop ::> &type[1..1](Singleton) <-> usedBy : C:Entity projectOn ((P:belongsTo.P:belongsTo.P:entities) union (P:belongsTo.P:belongsTo.P:importedPackages.P:entities)), &includedContext[0..*](Set) : C:EntityObject := (P:belongsTo.P:belongsTo.P:importedPackages) ;

▶ The context sensitive domain of the “type” property realizes the visibility feature: an association cannot reference entities of foreign packages that have not been imported.

▶ The inferred property “includedContext” implements the scoping feature: all imported packages are included into the scope of an association.

2011/05/24

Visibility

Scoping


Constrain property/value assignments within instances according to the type of the instance▶ This can be realized with a context sensitive domain. Let’s

show the relevant part of the concept PropertyValue:

▶ PropertyValue! refines EntityObject ::> (PK)&property[0..1](Singleton) : C:Prop projectOn (P:belongsTo.P:entity.P:properties), ...

▶ The Edge Algebra statement ensures that the referenced property within a property/value assignment is a property that is defined within the type of the instance.

2011/05/24


Domain model with package imports

2011/05/24


Task 1.5 - Integrating manually written code (again in Java, C# or C++)▶ Challenge: Integrate derived attributes to entities.

Note that if you want, you can also define or reuse an expression language that allows defining the algorithm for calculating the age directly in the model. Ideally, you will show both (manually written 3GL code as well as an expression language).

2011/05/24

entity Person { string name string firstname date birthdate Car ownedCar derived int age // somehow somewhere implement the code // to calculate age}


Introducing a simple expression language

▶ We have decided to implement a simple expression language that allows defining the algorithm for calculating the age directly in the model.

▶ entity Person { date birthdate derived natural age = YearOf((Today - P(birthdate)))}

2011/05/24


The language module „Expression“

2011/05/24


The language module „Expression“

▶ Today!! refines DateExp ::> ;▶ DateSubtraction!! refines DateExp ::>

leftOperand[1..1](Singleton) : C:DateExp, rightOperand[1..1](Singleton) : C:DateExp ;

▶ YearOf!! refines NaturalExp ::> dateExp[1..1](Singleton) : C:DateExp ;

▶ textual concrete syntax LWC { <default> DateSubtraction : "(" (P:leftOperand) _ "-" _ (P:rightOperand) ")" ; <default> Today : "Today" ; <default> YearOf : "YearOf" "(" (P:dateExp) ")" ;}

2011/05/24


Enhancement of the language module „Domain“▶ DateProperty!! refines DateExp ::>

&attr[1..1](Singleton) : C:Attribute projectOn (P:context.P:attributes) where typeSafety["The referenced attribute must be of type Date"]: (P:attr.P:type) consistsOf C:P_Date ;

▶ Derived! refines Prop ::> type[1..1](Singleton) : C:Primitive, expression[1..1](Singleton) : C:Expression, &context[0..1](Singleton) : C:EntityObject := (P:parent.P:context) where typeSafety["Return type must match the expression's type"]: (P:type consistsOf C:P_Boolean => P:expression consistsOf C:BooleanExp) & (P:type consistsOf C:P_Date => P:expression consistsOf C:DateExp) & (P:type consistsOf C:P_Natural => P:expression consistsOf C:NaturalExp) & (P:type consistsOf C:P_String => P:expression consistsOf C:StringExp) ;

2011/05/24


Enhancement of the language module „Domain“▶ textual concrete syntax LWC {

<default> DateProperty : "P" "(" (&P:attr) ")" ; <default> Derived : "derived" _ (P:type) _ <Named> _ "=" _ (P:expression) ;}

2011/05/24


Domain model with derived property

2011/05/24


Task 1.6 - Multiple generators

▶ Challenge: Generate some kind of XML structure from the entity model.

▶ Solution: We enhanced the Xpand based code generator from task 0.2. This can be done in two simple steps:▸ Code another Xpand template▸ Enhance the workflow

2011/05/24

Due to time restrictions the code generation task is not explained here. Please have a look at our online documentation of the LWC2011 case.


Phase 2 – Non-functional


Task 2.1 - How to evolve the DSL without breaking existing models

▶ How to evolve concrete syntaxes of a DSL without breaking existing models?

▶ How to evolve the abstract syntax of a DSL without breaking existing models?

2011/05/24

M E T A M O D E L - M2L –

Abstract Syntax

Concrete SyntaxConcrete Syntax


Task 2.1 - How to evolve the DSL without breaking existing models

2011/05/24

How to evolve concrete syntaxes?‣ In fact you can alter concrete syntaxes of a DSL

at runtime – even if your model repository already contains instances of your DSL.

‣ As soon as you change the concrete syntax of your metamodel, the respective models will be immediately updated by the model repository.

‣ Textual representation of a model is just a projection of an object graph to text and thus – by changing the concrete syntax – the projection rules are changed and interpreted accordingly.

How to evolve the abstract syntax?‣ Migration of a model can be implemented with ATL

– it’s just a model-to-model transformation.‣ Moreover you can use our Java API to

programmatically access the contents of a model repository and store those contents into another repository with some other structure.


Task 2.2 - How to work with the models efficiently in the team

2011/05/24

Third-partyDatabases

OOMEGAMemoryDB

SDF – Structured Data FormatXML – Extensible Markup Language

Text – according to your concrete syntax

db4objectsHibernate

Versant Object Database

CLIENT

MIDDLEWARE

BACKEND

OOMEGANetwork Layer

API

API

API

Modelling UIwithin EclipseATL Xpand

Multi-user synchronisationincl. notifications


Task 2.2 - How to work with the models efficiently in the team

2011/05/24

MemoryDB and Apache Subversion‣ SDF – Structured Data Format

SDF is the appropriate format, if your model is shared between several team members but not concurrently modified.

‣ XML – Extensible Markup LanguageXML is the best choice, if your model is shared between several team members and only concurrently modified in rare cases.

‣ Text – according to your default concrete syntax specificationIf your models will be often concurrently modified by several team members, then you should opt for storing and sharing your models according to your default concrete syntax specification.

Third-party database bindings‣ Concurrent Editing

Users can edit model elements concurrently – even if they change exactly the same objects; there are no read/write locks acquired at the server when reading or changing some contents.

‣ Transaction IsolationLocal changes to the model won’t be visible to other users as long as those changes are not committed to the database (transaction isolation).

‣ NotificationsAs soon as local changes are committed to the database (the modeller hits the Save button in the Eclipse workbench), concurrent transactions of other users will be instantly notified by those changes.

You will notice the changes of other team members online – text passages might be changed by others, graphical boxes may arise or might be moved,

etc.


Task 2.3 - Demonstrate Scalability of the tools

▶ Large-scale modelsthe language workbench must be able to handle large-scale models with possibly millions of objects in the model repository.

▶ High degree of concurrent modellingthe language workbench must allow a high degree of concurrent modelling with possibly hundreds or thousands of transactions editing the contents of the model repository concurrently.

2011/05/24

OOMEGA’s solution for aforementioned challenges: we provide bindings to high-performance third-party databases.

Versant Object Database is best-suited for that purpose.


Phase 3 - Freestyle


Cool Features

▶ Eclipse-based solution & Support for ATL and XpandOOMEGA is based on the Eclipse IDE; it supports ATL and Xpand for model-to-model and model-to-text transformations.

▶ Scannerless parserOOMEGA has implemented its own scannerless parser; we do not rely on ANTLR or some other parser generator.

▶ Text editors with syntax highlighting, linking and incremental parsingAll you need to do is to specify abstract and concrete syntaxes of your domain-specific languages; OOMEGA will instantly provide a comfortable text editor with syntax highlighting, linking and incremental parsing. No programming effort required!

▶ Object-oriented database back-endYou can edit your models with an Eclipse-based text editor. Anyway, the storage back-end is always a database: when you type some text in the editor, objects are instantly created in the context of a database transaction. As soon as you press the Eclipse “Save” button, your database transaction is committed.

2011/05/24


Cool Features

▶ Various implementations of object-oriented storage back-endsThere are various implementations of OOMEGA’s persistency API available. You might choose to store and share your models with a relational or object-oriented database. But you can also use file-based storage back-ends on the basis of our binary codec SDF, our XML support or your textual concrete syntax definition. Irrespective of your concrete choice, the editors interact with the models on the basis of our object-oriented database API.

▶ Clear separation of abstract and concrete syntaxesWe strictly distinguish between abstract and concrete syntax definitions. The abstract syntax defines the structure of the model whereas the concrete syntax only bridges the gap between this structure and a concrete textual representation of the model. Therefore it’s easy to define several concrete syntaxes for one and the same abstract syntax.

▶ Graphical or form-based editorsIt’s possible to combine text editors with graphical or form-based editors. You can embed those special editors in additional syntax tabs. The observer pattern of OOMEGA’s API will ensure that changes made in the text editor will instantly update your graphical or form-based editors, and vice versa.

2011/05/24


Cool Features

▶ M2L and the Edge AlgebraOur metamodelling language M2L and its foundation – the Edge Algebra – allow very accurate abstract syntax specifications. It’s a very powerful and compact language. Please remember: we were able to implement the whole functionality of the LWC2011 case in less than 350 lines of code and didn’t require a single line of additional 3GL code for designing the language, implementing constraints or setting up text editors.

▶ Various techniques for defining constraintsM2L and the Edge Algebra provide various techniques for constraining your models: primary local keys, context sensitive domains, weak entity and attribute concepts, multiplicities, abstract concepts, and additional constraints. All these constraints are guaranteed by the storage back-end, thus it’s impossible to commit an invalid state of a model. Due to the advanced metamodelling concepts you can very accurately specify the range of valid models – far beyond traditional data modelling techniques.

▶ Multi-user support via online interaction or CVS/SVN repositoryOOMEGA supports multi-user environments via online interaction on top of database back-ends. We have invented and implemented a highly interactive multi-user synchronisation mechanism that is similar but not identical to the well-known optimistic locking scheme: you will instantly receive committed updates from other users in your language workbench. Moreover you might choose to share your models with a standard CVS or SVN repository.

2011/05/24


Thank you!

2011/05/24

language workbench competition 2011 the oomega language workbench

Documents

oomega language workbenchwww

language modularity

separation of abstract

abstract conceptscant

text transformationswww

number of referenced

concrete syntaxes

christian merenda20110524www