Writing Constraints, Model-to-Model, and Model-to-Text Transformations

Corrections in RED

Find a partner.  You are to work in groups of 2 in this (and other) programming assignments.

This assignment is aimed at covering the major bases in MDE: constraints, M2M, and M2T transformations using MDELite.  Start by downloading MDELite7 and installing it in some convenient directory. MDELite was developed in Windows and should work in Mac and Linux environments -- no guarantees though!

We reviewed in class the ATL family-to-persons application and its corresponding MDELite program.  This assignment is based on families-to-persons -- you will write a:

  1. Conformance program for families2 database
  2. Model-to-model transformatin of a families2 database to a families1 database
  3. Model-to-text transformation to report the contents of a families1 database.

Here is the main method of a Java class that invokes all three programs that you are to write.  Comment out the programs that you haven't written until all are implemented.

    public static void main(String[] args) throws Exception {  //<-- program #1
try {
// bad.families2.pl will fail to conform.
ConformFamilies2.main("bad.families2.pl"); //<-- program #2
} catch (Exception e) {
System.out.println(e.getMessage());
}
ConformFamilies2.main("inria.families2.pl"); //<-- program #2 (called again)
M2M.main("inria.families2.pl"); //<-- program #3
M2T.main("inria.families1.pl"); //<-- program #4 (called again)
}

For each part, do the reading assignment before you proceed.

Note: MDELite is not a tiny package.  It may take you some time to work your way through it and its documentation.  Please feel free to post me email/Piazza notes on how to do <whatever>?; I'd be glad to save you some time with advice.  If you have problems/bugs again, if I can help, let me know.  The programs you are to write are not long, but they're dense.

Part 1: Constraints

From the MDELite Documents, read:
Also note that the following code fragments will be your friend:
Table myTable = ...;  // initialize table

myTable.print(); // print contents of table to System.out
And finally, review the class notes on ATL Families; see this too.

Recall the ATL Families metamodel, shown below:



An MDELite database of the original ATL example is inria.families2.pl.  This design is a bit strange as it takes some time to understand.  In particular, note the following:

What to Submit for Part 1


Part 2: M2M Transformations

From the MDELite Documents, read:


There are two different but equivalent schemas for the family database.  I used f2 below -- which I used to transform a families2 database to a person database.  In f2, father and mother information is stored with each member.  Alternatively, I could have stored a family link in the member table and added a boolean to indicate whether the member was male or female.  That's f1 below.

Here are some files for you:


You are to write an M2M MDELite Java program that transforms inria.families2.pl to its corresponding inria.families1.pl counterpart.  Note that the tables of inria.families1.pl should be sorted by (increasing) tuple identifier.

What to Submit for Part 2



Part 3: M2T Transformations

From the MDELite Documents, read:


A Model-to-Text (M2T) or database-to-text transformation in MDELite uses the RunningBear (RB) tool.  You are to translate a .families1.pl file (namely the inria.families1.pl that your M2M program produced) to the following output:

Brandon March has parents Jim and Cindy
Brenda March has parents Jim and Cindy
David Sailor has parents Peter and Jackie
Dylan Sailor has parents Peter and Jackie
Kelly Sailor has parents Peter and Jackie
Jim March has <unknown> parents
Cindy March has <unknown> parents
Peter Sailor has <unknown> parents
Jackie Sailor has <unknown> parents

What to Submit for Part 3


What to Submit to Canvas

  1. a single zip file
  2. the request for Part 1
  3. the request for Part 2
  4. the request for Part 3
  5. Remember to put your name and email address at the top of your submitted PDF file.

A critical part of any design is clarity and understandability.   Hence, you will be graded on the clarity of your project and its ability to work correctly.  Sloppy code, documentation, or anything that makes grading or understanding your program difficult will cost you points.  Beware, some of these "beauty" points are subjective. 

Remember: No late assignments/submissions will be accepted.