wiki:WikiStart
Last modified 4 years ago Last modified on 01/28/13 09:53:31
This is NOT the official page of ScheMoL.

Visit http://code.google.com/a/eclipselabs.org/p/schemol/

Welcome to ScheMoL

Schemol is a domain-specific language for extracting model from databases which incorporates a powerful query language to navigate the database schema and to extract information from databases. The language is deeply inspired by Gra2MoL, which is code-to-model transformation language. Likewise Gra2MoL, ScheMoL is a rule-based transformation language and also uses the concept of binding as ATL [3], which was adapted to deal with tuples. In this sense, the source element of a rule is a database element (i.e., table) rather than a metamodel element.

Description

Model Driven Engineering (MDE) is not only applicable for creating new software systems, but it can also be used for modernizing or reengineering existing systems. In model driven reengineering, reverse engineering techniques are used to extract models that are high-level abstractions of the information of the source software system artefacts. These models are later transformed to obtain models which represent the redesigned system conforming to the target architecture. Finally, forward engineering techniques generate the target software system artefacts. Whereas there are several languages to perform model-to-model transformations and generate the system artefacts (i.e., model-to-text transformations), the extraction of models from the system artefact is normally carried out by means of ad hoc solutions.

Extracting models from both source code and data is an essential task in software reengineering because they are commonly the main assets of an application. There are currently several approaches which address model-driven code reverse engineering. However, little attention has been paid to data reverse engineering using MDE techniques. In fact, the extraction of model from relational data is normally performed by means of ad hoc solutions or object-relational mappers, which require performing hard and time-consuming tasks. Bearing these problems in mind, we created ScheMoL, a Domain-Specific Language (DSL) for extracting models from relational data.

Syntax

These are some examples of the ScheMoL syntax

Preamble

PREAMBLE
 CONSTRAINTS
  Table tableName( 
   primaryKey (columnNameA)
   foreignKey (columnNameA) REFERENCES tableNameB(columnNameB)
  )
   ...
 END_CONSTRAINTS
 VIEWS
  CREATE VIEW schemaName.tableName (columnNames) AS  SELECT ...;
  END_VIEWS
END_PREAMBLE 

Preamble example

PREAMBLE
 CONSTRAINTS
  Table student (
   primaryKey (id)
   foreignKey (tutor) REFERENCES lecturer(id)
  )
  Table registration (
   primaryKey (aSubject, aStudent)
   foreignKey (aSubject) REFERENCES subject(code)
  )
 END_CONSTRAINTS
 VIEWS
  CREATE VIEW `university`.`course` (`title`, `totalCredits`) AS  SELECT `course`,sum(`credits`) FROM subject group by `course`;
 END_VIEWS
END_PREAMBLE 

Rules

There are two types of rules in Schemol: top rules and normal rules. Top rules are the starting point of the transformations chain and they are always trigger directly, without being called by any other rule.

toprule 'ruleName'
 from schemaName::tableName fromId
 to packageName::className toId
 filter
  expression
 mapping
  toId.attributeName = query || expression
end_rule

The normal rules are called by a top rule or by other normal rules, depending on the references of the previously executed rules.

rule 'ruleName'
 from schemaName::tableName fromId
 to packageName::className toId
 filter
  expression
 mapping
  toId.attributeName = expression
end_rule

Any of the before kind of rules can have a different behaviour if the target element is not directly table-dependant. If a new element of our metamodel needs to be created but it has no direct mapping from the database, a DBElement can be used as From part (i.e. as source of the transformation)

rule 'ruleName'
 from Database fromId
 to packageName::className toId
 filter
  expression
 mapping
  toId.attributeName = expression
end_rule

Rules example

rule 'mapStudents'
 from university::student stud
 to university::Student uStu
 mapping
  uStu.classmates = stud.@registration.aSubject.@registration.aStudent; 
  uStu.name = stud.name;
  uStu.surname = stud.surname;
  uStu.telephones = stud.@phone.aPhone;  
  uStu.subjects = stud.@registration.aSubject;
  uStu.universityCode = "Student"+ stud.id;
  uStu.tutor = stud.tutor;
end_rule

rule 'mapAssociateProfessor'
   from university::lecturer lect
   to university::AssociateProfessor asso
   filter
      l.salary >= 2000 && l.salary < 3000
   mapping
      asso.name = lect.name;
      asso.surname = lect.surname;
      asso.salary = lect.salary;
      asso.department = lect.department;
end_rule

toprule 'mapUniversity'
   from Database db
   to University u
   mapping
      u.subjects = db.@subject;
      u.courses = db.@course;
      u.people = db.@lecturer;
      u.people = db.@student;
end_rule

Filters

Filters are parts where some conditions are checked. Filters are optional parts of the rules.

Filters in rules

The conditions are checked against the from part. If the conditions are satisfied, the rule is triggered.

rule 'ruleName'
 from schemaName::tableName fromId
 to packageName::className toId
 filter
  expression
 mapping |fromId, toId|
  toId.attributeName = expression
end_rule

Filters in queries

The conditions are checked against the query, filtering the returned results. The queryAttributeToFilter is the name of the column pertaining to the @query table which we want to filter by. The value can be a expression (e.g. string, int, fromId.attribute...). More than one filter can be used linking the different filters with && (e.g. fromId.@query{filter1 && filter2};

mapping
 toId.attributeName = fromId.@query{queryAttributeToFilter = value};

Web-based examples

ScheMoL has been extensively tested by the ONEKIN research group. You can find the examples developed here.

Attachments