MOFLON Bootstrap
From the very beginning, MOFLON has consequently followed a bootstrapping approach. Each version of the metamodel used by the MOF2.0 editor and the code generator are generated using a previous version of MOFLON. Besides, a MOF2.0 meta-metamodel instance is generated, that can be queried for metamodel-information during runtime. Considering the complexity of the underlying metamodel, the major benefit of this approach is, that we receive immediate feedback on bugs in our code generator and thus can finally deliver a high quality tool. As we will discuss 
below, this process also revealed a considerable number of shortcomings with respect to the precise semantics of the official UML 2.0 / MOF 2.0 specification. We were able to find solutions for these issues and exploit them in the MOFLON tool [AS06].
Initial Bootstrap approach with MOMoC
The initial version was created using the console-based MOMoC generator, which was a predecessor project at the University of the Federal Armed Forces Germany, Munich [Bic04]. A simplified MOF 2.0 metamodel was maintained as Rational Rose model and imported into MOMoC as XMI file and represented internally as a MOF 1.4-compliant model. From this representation, MOMoC could generate a Java representation with tailored (i.e. typed) JMI interfaces and a corresponding implementation.
Current Bootstrap approach with MOFLON
The MOFLON project extends MOMoC with a much more sophisticated, MOF 2.0-based JMI representation. It features fully implemented tailored and reflective interfaces, corresponding XMI representation and an in-memory MOF 2.0 instance as meta-metamodel representation. On top of this standard-conform core, MOFLON provides over a suitable graphical user interface and incorporates graph transformations, OCL 2.0 constraints, and QVT-compliant Triple Graph Grammar implementation into the approach.
Evaluation of the UML 2.0/MOF 2.0 specification
As MOFLON implements the MOF 2.0 specification (i. e. mostly the UML 2.0 Infrastructure Library), its semantics must be defined precisely. However, we found numerous errors and missing constraints in the specification, which we needed to repair to be able to implement MOFLON, as discussed in [AS06]. The complete list of identified inconsistencies and its corrections can be found here. Summarizing, we found the following results:
| From 90 analyzed constraints of the specification, | 42 (47%) are erroneous |  | 48(53%) are correct |
| To 86 constraints 101 improvements have been applied, of which | 50(50%) are additional constraints |  | 51(50%) are corrections |
| From the 51 corrections of the specification, | 16(29%) are due to a wrong metamodel reference |  | 19(34%) are due to wrong semantics |
| 21(37%) are due to wrong syntax |