Aocl

Tooling in MDE is a long-term problem.  Aocl is a response to this.  It is a pure-Java alternative for OCL (Object Constraint Language) and other specialized languages used in MDE today.  Aocl has syntax similar to that OCL -- except with a Java favor.  Here is the original paper on Aocl.  This document shows you how to use Aocl.  The big picture is in text and category diagram below:
That's it.  Follow the links above to learn more about each step.




Write a CDSpec of Your Class Diagram

The first step is to define the class diagram (no constraints!) of your target metamodel.  This is written as a CDSpec file, which is documented here.  An example file, startrek.cdspec.pl, is shown below, along with its PlantUML png file. (Click here to see how to generate this png file).


:::DocGen/Production/StarTrek.cdspec.pl:::


Converting a CDSpec to Aocl

The Meta4 tool takes a single .cdspec.pl file as input (whose tail ".cdspec.pl" is added if not given):

:::DocGen/Production/output/StarTrekM4.txt:::

Meta4 promptly converts the CDSpec file into a CD file and runs conformance tests.  If no errors are produced, Meta4 proceeds to create a package under its NetBeans directory Meta4/Allegory/x, where x is the name of the x.cdspec.pl file that was submitted.  A set of files are produced; they are:
These files are discussed in a bit more detail below.

Schema File

Here is the MDELite relational schema declaration derived from StarTrek.cdspec.pl:  There are 4 tables (Crewman, Commander, Lieutenant, and Starship), each with their own attributes.  All tuples start with a String identifier field, id.  Object diagrams that conform to the StarTrek.cdspec.pl file are database files (with name y.StartTrek.pl)  that conform to the schema below.
:::DocGen/st/StarTrek.schema.pl:::

Tuple Files (<T>.java)

Look at the Crewman class. It has 3 fields, fname, lname, and onBoard. It also has a (manufactured) id, which is inherited from superclass TuPle and is always the first field of a tuple, otherwise there is nothing special here.
---Start---
Nowjjjjj, let's look at the rest of Crewman.  There is a  toString method that uses the Java String Formatter.  The only unusual thing here is the expression "__(onboard)", which extracts the String id field of the referenced Starship tuple.  The onBoard() method  implements a right-semijoin: given a Crewman tuple a Starship table with a single tuple (the Starship to which this Crewman is assigned) is returned.
---Finish---
Now look at the Lieutenant class, a subclass of Crewman. It has 5 fields, 4 of which are inherited from Crewman, and one (speciality) specified to Lieutenants. (A call to the Crewman constructor could have been used, but it was easy enough to simply unroll the assignments of all superclass constructors).
---StartL---
The rest of Lieutenant is similar to Crewman: there is a  toString method that uses the Java String Formatter.  The onBoard()  right-semijoin method is inherited from Crewman.
---FinishL---

Table Files (<T>Table.java)

Now let's look at the CrewmanTable.  It has constructors to create empty or singleton tables -- these are tables that eventually will contain the result of some relational table operation.
---StartTab---
The next methods are for projecting singleton columns of primitive types into a 1-column table; it is important for these operations to preserve duplicates.
---GettersTab---
The final method, onBoard(), implements a right-semijoin of a (qualified) table of Crewman tuples with the full Starship table; duplicate Starship tuples are removed:
---FinalTab---

Database File

A Database object contains a set of tables, in this case, a table for Crewman
---StartDB1---
... // internal details of database loading
---StartDB2---