Alternatively, a tool could have the
modeling language itself as data, rather than as code, and functionality could be
provided for altering this data, in the same way as was done in the early text-based
tools. Aweakened form of the latter was a hybrid of the two: the modeling language
was expressed in data or a mixture of data-like and code-like parts, which were
transformed into code and compiled and linked with the generic modules.
The former solution was the one largely adopted by industry, in turning out new
versions of an existing code base for new modeling languages. The approach however
had ?¬‚aws from the users??™ point of view: only the vendor could make the changes, and
the cost of such changes was high. While the reduction in work to make a modeling tool
for a new modeling language was signi?¬?cant (one manufacturer claimed reuse as high
as 90% (Rust, 1994)), the rate of such adaptation still proved insuf?¬?cient to satisfy
users??™ needs. Furthermore, the cycle from requesting a change to using the modi?¬?ed
tool was painfully long, and the customer was left highly dependent on the vendor.
360 TOOLS FOR DSM
The latter solution, called CASE shells (Bubenko, 1988) or metaCASE tools
(Alderson, 1991), produced promising research prototypes and a few somewhat
limited commercial products.
Pages:
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686