Concrete Syntax

For a detailled syntax definition see the ANTLR grammar Megalib.g4 and the examples located in the folder models.

Statements:

Anything has to be declared before it is used. Thus, the order of the statements plays a role in the technology model. At best, it is not necessary to declare new subtypes of Entity or relations in a module, since the prelude holds the most general declarations.

Comments

Further, any block of statements has to begin with a block comment. Type level statements begin with a simple block comment that only serves as a headline. Instance level statements begin with a block comment contain two annotation. The @Description marks the start of a headline. @Rationale serves the purpose of traceability. We use a rationale to raise transparency and traceability on where the information was mined that is modelled.

/*
  @Description:
    ANTLR is a "parser-generator". Thus, it is a framework used to generate parsers.
  @Rationale:
    See https://github.com/antlr/antlr4
*/

Type Level Statements

• There exist several subtypes of entity. They define the kinds of entities that we want to talk about in our megamodels. A subtype can have further subtype, if there exists a primary classifier. In the case of languages, the primary classifier is the purpose of the language.

     Artifact < Entity.
     ProgrammingLanguage < Language.
  

• Relation Declaration:

     partOf < Artifact # Artifact.
     uses < Artifact # Language.
  

Instance Level Statements

• Instantiation:

     Controller : Artifact.
     Java : ProgrammingLanguage.
  

• Relation Instantiation:

     Controller partOf ControllerPackage.
     Controller uses Java.
  

• Descriptive Link with URL or Filepath for further Reading:

     MegaL = "http://softlang.org/megal".
     MegaL = "file://../docs/languageDescription.pdf".
  

• Binding artifacts to where the modelled artifacts actually live:

     javaFile1 ~= "http://softlang.org/JavaFile1.java".
     javaFile1 ~= "file://../org/softlang/JavaFile1.java".
  

• Syntactic sugar in analogy to RDF Turtle syntax (';' as a sequence separator and '.' after any sequence):

     javaFile1 : File;
         ~= "<pathToJavaFile1>";
         elementOf Java;
         hasRole Script.
  

• Function Declaration:

     functionA: Java -> SubJava # SubJava.
     functionB: SubJava # Java -> Java # SubJava.
     functionC: SubJava # Java -> SubJava.
  

• Function Application:

     functionA (javaFile1) |-> (javaFile2,javaFile2).
     functionB (javaFile2, javaFile1) |-> (javaFile1, javaFile2).
     functionC (javaFile2, javaFile1) |-> javaFile2.
  

Modularization

• Any technology model written in MegaL should be organized in multiple modules. In this case every .megal-file that represents a module starts with a declared name.

     module rubyOnRails.ActiveRecord
  

• A module's name encodes information on a folder that contains it. In the example above the folder the file is in has to be called 'rubyOnRails'. Only then, another module can import this module. Import statements come after the module name. The import mechanism works in a similar way as in Java or Haskell etc.

     import rubyOnRails.ActiveRecord
  

• The modularization further supports the reuse of knowledge mentioned at Knowledge Levels. The statement for a substitution is shown below.

     import java.Jackson where{
         [sampleCompany / ?jsonFile,
         companyJava / ?javaClass,
         companyObject / ?model]
     }
  

• Further, MegaLText supports context sensitive substitutions. In the example below, we relate to Django's facilitation for using MVC. Imagine, the module 'django.MVC' would state that in any Django application there is a model artifact and a view artifact. These two are consistent (or otherwise related). To go further, we want to model a scenario where there are two models app1model and app2model and two views app2model and app2view. To avoid that the substitution process spits out a result in which app1model would be consistent with app2view, we put each pair in a separate substitution group.

     import django.MVC where {
       [app1model / ?model,
        app1view / ?view];
  
       [app2model / ?model,
        app2view / ?view]
     }