Java Reference
In-Depth Information
COMMENT
Any plan to standardize a general-purpose model or set of models will
likely continue to fail because humans inherently need to express their own
creativity (Not Invented Here [NIH] syndrome). Furthermore, the level of
investment required to learn a large and complex language, become famil-
iar with the associated tools, and then incorporate them into a develop-
ment process makes the approach too costly for many. Therefore, when
modeling is advantageous but using standards-based modeling languages is
not, the alternative is to use tooling that facilitates the creation of DSLs.
1.2.1 Why Develop a DSL?
Definitions and perspectives aside, why would you choose to develop your own
DSL? Most people prefer to begin with something small and grow it as required,
which is likely how the UML itself got started. The key difference today is that
UML and its associated tooling is now large and complex, whereas tools for rap-
idly developing custom domain-specific products are more readily available.
That said, in the process of creating, maturing, and extending your DSL or fam-
ily of DSLs, you might end up with something akin to UML. The difference is
that you're using your organization's family of models, transformation defini-
tions, and generation facilities, which are tailored to your exact needs.
Don't interpret this the wrong way: My intention is not to disparage UML.
The point is that whether your DSL is defined using the UML or a smaller lan-
guage such as Ecore, you can create a set of tooling around your DSL in a largely
generative manner. Historically, this was not the case: Modelers were forced to
buy expensive, inflexible, closed modeling tools that inevitably required cus-
tomization. Today Toolsmiths can develop custom tooling using the capabilities
of a strong open source foundation provided by the Modeling project. This
changes the playing field for modeling tools and MDSD in general.
Finally, because a library of models and model transformations likely will be
available for reuse, the capability to assemble DSL-based applications that build
on MDSD techniques becomes even more attractive. For example, the GMT proj-
ect [37] has already begun building such a library. Thanks to the use of available
DSLs, along with a growing number of target application frameworks, the result-
ing abstraction gap has sufficiently shrunk to the point at which MDSD is an
increasingly attractive approach to delivering software.
Search WWH ::
Custom Search