All suffer heavily from this mismatch. It would be ironic if just at the point
where our industry has acknowledged that UML has failed as a way of building
applications (as opposed to describing them), and is moving toward DSM as the best
way forward, DSM environments were to blinker themselves into offering UML as a
way of building modeling applications.
396 TOOLS FOR DSM
CHAPTER 15
DSM IN USE
Section 13.4.3 already looked brie?¬‚y at some of the issues of the use of the Domain-
Speci?¬?c Modeling (DSM) solution from the point of view of the modelers. In this
chapter, we will discuss in more detail those aspects of modeling that are not already
covered by the decisions made in the DSM solution, and also look at some such
decisions that can only really be made when wider issues of use are considered.
In many of these areas, DSM works rather differently from code-based development.
Although this is to be expected, it often comes as a surprise to ?¬?nd that some
accepted wisdom and truths held as self-evident were actually only valid in the context
of code-based development. Some of the ???version 1.0??? DSM environments have not
yet discovered these differences and try to store the new wine of DSM in the old
wineskins of textual programming languages. In this chapter, we will assume an
object-oriented approach to models and model storage and seek the best solutions for
DSM: once we know where we are heading, we can better decide whether we want to
make transitionary concessions to existing practices.
Pages:
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765