1 CASE or UML tool versus DSM tool
60 DSM DEFINED
resources, the increasing cost of having a DSM solution limits the number of cases in
which automation can be applied. In addition to creation time, we also need to
consider the maintenance of the DSM solution: costly and time-consuming
modi?¬?cations to languages and generators can hinder the development process.
Usually developers can??™t wait long for a newer version of theDSMsolution. The most
important reason for a ef?¬?cient tool implementation is obviously the value of having
the automation in use as early as possible.
Dif?¬?culty of DSM Tool Development. Building a DSM solution should be
possible without having to program the DSM tool. Metamodeling tools of the early
1990s, which could generally only be used by the people who built them, made the
creation of DSM solutions too dif?¬?cult and resource intensive. This limited the
availability of domain-speci?¬?c tools to only larger companies. At best the developers
of a DSM solution would only need to de?¬?ne their language and generators, along
with a domain framework to support the generated code and the tool should provide
the rest. In this book, we follow this ideal and focus on de?¬?ning and using modeling
languages, generators, and domain frameworks. Tool implementation details are
intentionally outside the scope of this book.
Pages:
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136