Java Reference
In-Depth Information
MDSD can make use of many approaches and technologies. The Modeling proj-
ect provides many such technologies for use in MDSD, whether standards based
(such as when using UML2, Object Constraint Language [OCL], and Query/
View/Transformation [QVT] implementations) or non-standards based (such as
when using Xpand, Atlas Transformation Language [ATL], and so on).
Technically, Ecore itself is a “near-standard” implementation of the Essential
Meta-Object Facility (EMOF) metamodel. Discussions continue on aligning
Ecore and EMOF, as well as on the need for a Complete Meta-Object Facility
(CMOF) implementation within Modeling.
Not unlike the early days of domain and object modeling, the current idea of
MDSD is to focus on developing and refining the model of a particular domain
to provide a standard vocabulary for use in development. The key difference is
that, in the context of generative programming techniques, much of the work
that goes into developing a domain model (or DSL) can be used to produce
working software.
Volumes have been written on this subject [41], so I don't cover it again here;
this topic focuses on the practical reality of what can be done in this area using
the Modeling project. Still, it's worth discussing a couple relevant points: the
OMG's Model-Driven Architecture initiative (discussed in Appendix B, “Model-
Driven Architecture at Eclipse”) and software product lines, or software factories.
Perhaps the most compelling reason to leverage the Modeling project as a DSL
Toolkit is related to the development of software product lines. Using the
Modeling project to develop custom DSL tooling still requires significant effort,
so the most likely scenario for adoption is to produce a series of products, each
with a set of defined variation points. Using the facilities of the Modeling proj-
ect to produce a one-off custom DSL-based application is significantly easier
today than it was just a few years ago. However, the effort required to design a
DSL, author transformations and templates, and so on yields a greater return
when a product line is produced. Much has been written on the subject of prod-
uct line engineering, feature models [39], and the related concept of software fac-
tories [40].
The sample applications developed in this topic represent a simplistic exam-
ple of how a series of models is used to define various aspects of the software
requirements domain. The process and tooling needed for software requirements
largely depend on the methodology a team uses for development, so require-
ments solutions need to be quite flexible. Traditionally, this has meant providing
Search WWH ::
Custom Search