Java Reference
In-Depth Information
Requirement
objects, so we use
late resolveIn
to invoke this mapping at the
end of the transformation. The alternative here is to map dependencies in the
end{}
block of our main mapping. Section 13.5.5, “Mapping Invocation,” gives
an in-depth discussion of resolution operators in the context of this transformation.
Finally, note that
Relationship
references between root
Topic
elements are
missed, which is okay because root
Topic
s are mapped to
RequirementGroup
objects that have no dependency relationships.
Before testing this update to the transformation, we need to more completely
populate our
Mindmap.xmi
dynamic instance model. Add a few
Topic
s to the
Map
and include subtopic references, as well as at least one
DEPENDENCY
Relationship
to test our mappings fully. Figure 6-13 shows a simple test
model instance in our reflective Ecore editor.
Figure 6-13
Mindmap dynamic instance model
If we deploy the transformation and run it on an actual instance of a
mindmap model, the output will be a requirements model, as expected. However,
combining our EMF and GMF editors for our requirements model (done in
Section 4.4.6, “Integrating EMF and GMF Editors”) required us to persist both
the diagram and domain models within a single file. If we tried to open the result-
ing
*.requirements
file, we would get an error stating that the file contains no
diagram. Fortunately, the GMF-generated diagram-initialization action takes
care of the problem by initializing the diagram content and peristing the result
within a
*.requirements
file. When deploying the diagram and transforma-
tion, we want to provide an action that takes care of this step automatically after
the transformation.
To provide reporting for our mindmap, we use an
xhtml.ecore
model to serve
as the target of a model-to-model transformation. This approach complements the
one taken in Section 7.4, “Generating HTML,” where we use Xpand to generate
Search WWH ::
Custom Search