Ph.D. Thesis - Business Informatics Group
Ph.D. Thesis - Business Informatics Group
Ph.D. Thesis - Business Informatics Group
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
2.3 A DTD to Ecore Transformation Framework<br />
No Explicit <strong>Group</strong>ing Mechanism<br />
There is no explicit mechanism to group parts of a DTD that semantically belong together<br />
as it is supported in Ecore. Nevertheless, this deficiency can be bypassed by encapsulating<br />
parts of a DTD in separate files and employing parameter entities to import these separated<br />
definitions where appropriate.<br />
Missing Constraint Mechanism<br />
A mechanism for defining complex constraints, as it is supported in Ecore by using the<br />
OCL standard [OMG05d], is not provided for DTDs. Thus, even simple XOR constraints,<br />
which are often required in metamodels, cannot be specified. This deficiency is specifically<br />
problematic, since possible ambiguities in DTDs cannot be resolved and XML documents,<br />
while valid according to their DTD, might still not represent the domain data correctly.<br />
2.3 A DTD to Ecore Transformation Framework<br />
On the basis of the discussion of DTD and Ecore concepts as done in the previous section,<br />
it is now possible to give more insight into the semi-automatic transformation approach,<br />
which is based on previous work [SWK06]. Generally, the transformation approach consists<br />
of an automatic phase and a manual phase (cf. Figure 2.6). The first phase is responsible<br />
for automatically generating a first version of the WebML metamodel and is performed by a<br />
component called MetaModelGenerator (MMG). The metamodel generator employs, in a first<br />
step, a set of transformation rules expressing all identified non-ambiguous correspondences<br />
between DTD concepts and Ecore concepts (cf. Subsection 2.3.1). In a second step of that<br />
phase, a set of heuristics is applied, dealing mainly with the aforementioned deficiencies<br />
by proposing possible correspondences (cf. Subsection 2.3.2). On the basis of these suggestions,<br />
in the second phase, the user needs to manually validate the generated metamodel<br />
and refactor it accordingly (cf. Subsection 2.3.3). The implementation architecture of the<br />
transformation framework is presented in Subsection 2.3.4.<br />
M3<br />
DTD-Grammar Correspondences<br />
conformsTo<br />
implies<br />
conformsTo<br />
MOF<br />
Rules &<br />
Validation &<br />
M2 WebML DTD 1 Heuristics 2 Refactoring WebML Metamodel<br />
Figure 2.6: Two <strong>Ph</strong>ase Semi-Automatic Transformation Approach<br />
25